Autoload type loading code, stop loading everything on boot!

I think I mentioned that case…

If it is so that you can use it in other classes in the future, then again they are tightly coupled.

I suspose that applies to Enumerable? You’re misapplying the concept of ‘tightly coupled’…

Agreed. An importantly, the code only needs to lead the data when needed, which may be on load or later…

?

If class A is including module B, then A is tightly coupled to B

Next:
Traits and Mixins Are Not OOP

Noxw, we are getting somewhat off topic, aren’t we?

@kengey

The top voted answer in the stackoverflow link shows an example that is only applicable to strongly typed languages. The ‘bad’ example is compiling to a class def, the ‘good’ example is compiling to an interface def. Common practice when required.

The second article is ok, I read another by the same author. Main issue I have with his writing is it assumes one wants to code in a very strict OOP style, without really proving why that’s best. Also, discusses mixins violating the principal of encapsulation, but to reach that conclusion, again makes several assumptions. Also makes statements like:

“Such a tight coupling between mixins and object private structure leads to nothing but unmaintainable and difficult to understand code.”

He seems to be saying that mixins must use an object’s private structure. They don’t have to. Note that every interface that Enumerable requires is part of Array’s public interface. Regardless, I guess this somehow leads to "unmaintainable and difficult to understand”…

Anyway, if code doesn’t require polymorphic objects or runtime selection, why is it then considered improperly ‘tightly coupled’? Also, a lot of discussions of coupling totally ignore that lightweight objects normally want a bare minimum of data stored within them. As I see it, any time one ‘loosens coupling’, one often adds data to at least one of the objects…

In that sense, you are misapplying the ‘degree of coupling’ concept.

I think I’ve said something similar earlier, but I want to make clear that implementing a pattern without identifying a clear and distinct problem that it solves in your application, based on your app’s specs or requirements, now or in the future, is a waste of time…

Hi Greg,

The way one codes of course is very subjective. And I am aware that there simply is no correct answer. You say the author is a very strict OOP coder and I try to be that strict as well. Being that strict requires one to mostly ignore the beauty of ruby and what it allows you to do. I try to stick with SOLID (https://rubygarage.org/blog/solid-principles-of-ood) regardless of all other beautiful wizardry ruby allows you to do. I still am an architect I guess that once was teached Less is More.

Regarding the article that is only applicable to strongly typed languages… yes and no. It uses an interface which we do not have in ruby but the essence of the article is that if one literally types the name of another class (or module) in the code of another, that tightly couples one with the other. This has not so much to do with what I stated in the beginning of this thread, where I was a bit short and said modules are bad coding. It would have been better to nuance for what reasons I think they are bad:
Lot of code I have seen uses modules as business objects and have heavy module variables that get created upon requiring the code. I think that is bad because reading code into memory should be a separate action from executing code and initialising those module variables. This can be solved by the author, I know.
The second reason is the reason we are talking about right now: In strict OOP, it defeats SOLID (see link above)

Thus, we do not need to have Interfaces in Ruby to use the same concept. If 2 classes have the same public methods, they have the same interface.

For me it is not really that which makes modules bad, it is mere the fact that when class A includes module B you are separating the code of at least 1 class in 2 locations. That is more difficult to maintain than having a class in 1 spot and having a direct overview of what that class has and does.

Correct. But, for that reason I use a DI container that carries Proxies instead of the real object. So, imagine 1 object having a dependency on 3 others. Those 3 will have dependencies on their own I assume and so on. By wrapping everything in a proxy, the dependency will only be initialised when the holder will actually call it for a first time, saving a lot of object creations (except for the proxies of course). Here is an example of a DI container in Ruby, but, without proxies: Dependency Injection Containers vs Hard-coded Constants

Are you by any chance present at Devcamp in Leeds? I`d love to meet you in person, share a beer and have some more discussions about this, or maybe we already did at one of the basecamps I attended (in Vail or Steamboat Springs) or one of the other devcamps (Portugal, Italy, Greece or Leeds 2 years ago)? One thing written language does wrong is that it lets the reader do the intonation instead of the writer.

There might be some async nature to this which throws of measurements.

@kengey

I have yet to attend any SU conferences. I’ve attended plenty of trade shows and a handful of technical conferences. It’s always nice to meet people face to face over dinner or otherwise (beer, drinks, etc).

So, not this year, but maybe in the future…

2 Likes

It may make things a bit more indeterminate, but could one use AppObserver#onNewModel or AppObserver#onOpenModel for measurement? Haven’t tried…

I think that the order of things loaded differs a wee bit with the 2 platforms (at least it seemed to in the past.)

On Windows, I believe that just after all the extensions are loaded (and their menus and toolbars built,) the SU core calls any AppObserver#expectsStartupModelNotifications callbacks to find out if it should then call the appropriate other “model” callback. So this one can be used as a signal that the extension load cycle has ended, and that there is a valid model object ready.
Your test script would need to be the very first loaded in the “Plugins” folder.