refactoring modular structures in D - refactoring

Here's how I usually develop an application:
I start with having all the code in a single source file.
When it grows enough to be modularised, I break the code into several modules.
When the modules grow enough, I split them again. And so on, iteratively.
Over time, some modules get shrunk, deleted or merged with others.
This workflow implies the need to move source files between modules sometimes. And here comes the problem:
When I move a module to another location, it changes the module's name, so I have to walk through all the other files renaming imports by hand.
Is there some organisational technique to avoid that annoying procedure? Or is that the way it goes and I just have to look into some automation utilities instead?

you can create a *.all module that public imports all modules in the package
then you only need to add/remove the module names from that module

You can override module name via module packagename.modulename; directive in the beginning of the module. It will need a help from the build system though as rdmd uses module names from import statements to form file system path to search for their sources. But if you will supply all source files project consists from by hand, it should resolve module names just fine.

It's better to define your entities before you start coding. You can use some modelling language to identify and write your entities. For example if you are using java to code your application then you can use UML to model this application.
Also, you have to separate buisness logic from data.
If you continue to do it like today you will lose a lot of time just dealing with filenames.

Related

In a gem or lib, where should I create a sub-project that's closely related to a gem?

Let's say, I want to add a code-autogenerator for my gem/library. A code generator won't be a single executive cli file, but it'll contain source code as well as a cli file, and I'll be working on it too along with the main gem. Besides, it'll be written in a different language. I could move it into a different repository, but for now I've chosen to use a single repository. According to the convention, in what sub-directory in the main repository should I create that sub-project? opt, var, extra, tools....?
There is more likely no convention for a such situation and I think you already know the actually good solution: use a separate repository.
If this solution is not acceptable for now, a good option would be to put it in the folder with a name explaining its purpose. E.g. if it's a code generator, it could be inside "code_generator" or "tools/code_generator".

fbs project structure for PySide2 projects

Working with the excellent fbs tool (great stuff Michael!).
The manual has this suggestion about project structure:
As your application grows in complexity, you will likely want to split
its source code across multiple files. In this case, it is recommend
that you place them all inside one package.
My tendency is to use subdirectories like 'view','controller','model','service', etc wherein multiple .py files exist. Is there a critical reason one wouldn't want to use subdirectories when using fbs?

How can I overcome Golang's requirement that every package have buildable code in it?

I am building a web application in Go and as part of it I have several middelware functions defined. Right now they all live in "my/middleware" package. That namespace is becoming very cluttered by all the different functions I've defined so I decided to put them all in their own subdirectories, e.g. "my/middleware/gzip". When I do this I get the error:
no buildable Go source files my/middleware
I don't want all of these functions in the same namespace, but it seems my only option is to create a placeholder .go file in the my/middleware directory with an empty init function or something. That sounds terrible so I'd like suggestions on how to achieve my goal to group a similar class of packages when there isn't any shared/common code to live in the parent package.
You are actually taking the right decision by splitting the files into different subfolders. It is not different than what is done here
https://golang.org/pkg/compress/
This allows for the clients of your framework to take only what they need. The idea is to avoid dependency bloating. Go is all about being lean.
The error you receive is because you try to build a package that doesn't exist. Think of that folder as a logical grouping mechanism, you need to build the packages given by the child folders individually.

Processing - Accessing classes in subdirectory

I'm hitting this issue in this latest project where I'm looking to organise my code into subdirectories. However by doing so, the main application .pde file can't "see" the classes in the subdirectory.
Example - Say my folder structure is:
PFoo /
- PFoo.pde
PSystem /
- PSystem.pde
- Particle.pde
With PFoo.pde as my main application file, I can't seem to access the PSystem class or Particle class. Now, I guess the general consensus would be to develop a library to import or just deal with all the .pde files being in the same directory, however I'm wondering if there is something simple that I'm missing here that will enable me to quickly sort out the numerous class files that will be created. Something like a include "PSystem/PSystem.pde" or....
You can't have a tree structure in the Processing IDE unfortunately.
All your tabs from Processing end up being nested and compiled into a single Java class when you press Run.
I recommend using eclipse and you can easily nest your classes into java packages.
Additionally you can use the Proclipsing plugin which integrates nicely and makes it easier to manage libraries/export sketches/etc.

Any suggestions of a VB6 Source Code library?

I'm looking for a good VB6 source code library (to extend the language) for things like parsing a path into root, directory, filename, extension, does a file exist, etc.
I'm happy to pay for such a resource if it's a good one (ideally with some sort of reviews/feedback).
I've found one already:
SourcePlus from AxTools
Only downside is that all of their source code is in Classes and I have 12 or so different VB6 apps that all share a lot of common code (.bas modules). So if I use one of the classes in on of my Common.Bas routines I then need to add the class to 12 different programs that all use that Common.Bas module.
I'd really prefer to have the code in either one big class or a .bas module so I can add it one time to each VB6 app and be done with it.
FYI, I've also used with good success http://www.planet-source-code.com/vb/ and of course StackOverflow but I'd be happy to buy something comprehensive and well done.
I'm in favour of buying libraries in general, but you really can do a lot of file related tasks with free code. Karl E Peterson's excellent VB6 website has some great objects written entirely in VB6 - I think they're as reliable as most things I've ever bought. You could just put them in a COM DLL if you dislike managing the classes.
Convert a file path to drive and directory only.
Check whether a directory exists.
Check whether a file exists.
...I could go on
Can you build their source as a COM dll and just refer to it from your own projects?

Resources