Portability and Reuse

I’ve got several applications that are sharing code. All the shared code has been made external. This generally works well, but there is a problem of dependencies. For instance, if a Window object uses a class, the Window cannot contain the class. So right off, two items need to be imported. It can easily get to be bad, if one has not done a good job of keeping dependencies under control (ie like me). The window needs a class, the class needs a module, the module needs a different class, and so it goes. Bad design leads to a nightmare of dependencies.

I know this is nothing new, and I should fix me design. But before I do, I would like to know what features in xojo will make it easier to manage dependencies.

A possible solution is to put items in folders in a hierarchical fashion. But when using “import as external”, only one item can be selected at a time, and it cannot be a folder.

In some cases, a Window could be used as a container for various other parts, which works fairly well though a window cannot contain a class.

When it comes to class hierarchies, then one will need to import all the classes in the hierarchy. Maybe a way around this is to use interfaces rather than subclassing. I don’t know.

Its a common enough problem, I’m just curious what the best way is in Xojo to manage dependencies.

TIA

I haven’t run into those problems. But then, I import the entire directory. Hold the modifier key down while you drag the folder into your project. Everything comes in as external all in one shot.

Tim

Which modifier key? I can’t seem to get this working.

Simon.

Tim

I tried dragging a folder while holding down ALT. The effect was to import, not ‘import as external’. That is, the items are copies rather than references.

It seems that there is a need for something like a Java package. That is, a grouping of classes that can be brought in as a whole. If packages could contain packages, then one could build class hierarchies and easily select a branch and bring that in with all dependencies below it, assuming the design was hierarchical. The same effect could be achieved using folders to organize classes, if ‘import as external’ would allow the import of a folder.

Though such a package should not be limited to classes. One should be able to group any objects into a package.

A completely different approach would be to have the Xojo application take care of importing dependencies automatically. I believe this is called dependency injection, though that term is new to me and so not sure.

Just reading about current thinking on dependency management.

https://en.wikipedia.org/wiki/Dependency_inversion_principle

At a glance it seems the suggested solution is to use interfaces rather than subclassing. That is a partial solution, though I believe there needs to be a means of grouping things that supports hierarchies of groups.

I’ve just been looking at the Insert menu. It seems the most versatile container that can be imported with ‘import as external’ is the Module. And there is no container other than the folder that will contain all types of things. So it looks like the simplest addition that could be made to Xojo to help solve the dependency problem is to allow ‘import as external’ to import a folder. That is simple, as it is just a matter of doing a recursive folder listing, and applying the basic import operation to each item found.

A module can contain another module, so then any group of modules that must be kept together because they are interdependent might be grouped into a module.

But it seems a module containing modules can not be made external.

Further to this, while a module can contain another module, the IDE does not allow a module to be dragged and dropped into another module.

These two points are design flaws in the Xojo implementation, because they are inconsistent with the idea that a module can contain other modules. I think the design flaw is actually the idea that a module can contain another module.

Again, the simple solution is a general-purpose container that can be made external.

Another point worth noting is that Interfaces only support Methods, not Properties. So therefore an Interface is not a full replacement for subclassing.

[quote=266424:@Tom Dowad]Tim

I tried dragging a folder while holding down ALT. The effect was to import, not ‘import as external’. That is, the items are copies rather than references.[/quote]
You should consult the manual, but off the top of my head, I think it’s Control-Shift-Drag.

On a Mac it is Alt + Cmd + drag

Ya I’ve been blathering on about this problem when the real problem was that I was using the wrong command key combo. Its command-option/alt on the mac

BINGO!

Anyway…not a complete waste of time…

  • the menu item ‘import as external’ should be on the file menu without the need to hold down Alt
  • using the menu item rather than drag-and-drop should allow for importing a folder
  • modules containing modules and classes should either be made consistent with the IDE concept or be removed
  • Interfaces without properties do not provide a replacement for subclassing

Another weird thing that happens, sometimes when I have a Xojo project open, and the folder with the external things, then hold down Command-Alt, start dragging, and the Xojo window disappears!