2017-05-12 22:32 GMT+02:00 <[email protected]>: > On 12 May 2017 07:40:49 -0700, Eliot Miranda <[email protected]> > wrote: > > > Hi Cesar, > > [snipped] > > Hi Eliot, > > > > I'm on this vital industry for 45+ years and I already learned > > > that words and names have usages and except when standarized via > > > certains bodies aimed specifically the meaning can vary even > > > within the same realm of the art. > > > That written, and without attempting to start a semantic > > > discussion, however feeling a contribution may be useful, I would > > > say that the 'levels' one and two described above would better > > > called "modules" instead of plugins. > > > In my way of understanding this non mother tongue "compile time > > > plugins" seem to be more a figure of speech than the offering of > > > 'plugability' which plugins offer, or perhaps, in my humble > > > perception ought to offer. > > > Also, I think it would be less surprising for most people when > > > exposed to the subject (module == compiling, plugin == run time). > > > +1. I think the system designers agreed with you because the way to > > find out what plugins are available is > > Smalltalk listLoadedModules > > > Thank you Eliot! > > You'll not believe the number of times I typed and backtyped about > listLoadedModules! > > I keep thinking if I was not being too 'pushy' on my stance. . . :-) > > If after a serene consideration of the group and finding that would be > right direction for Pharo, we can consider breaking this method in > two: > > Smalltalk listLoadedModules > > Smalltalk listLoadedPlugins > > And in the future have this info exposed in the World menus. > > Regards, > -- > Cesar Rabak > >
But from the image POV is there any difference between an internal module and an external plugin ? If none, what would justify such split ? Additional complexity has to pay back or die.
