Today: PluggableListMorphByItem
Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s).
#2: If you cannot comment it, deprecate it. Laurent |
"Essentially useless in its current form. Probably
intended to eventually deal with actual objects in the list rather than
indexing/string-forms."
Regards, Gary
|
I hope one day we will have a comment like "I rock. I do wonderful things you never dream of. I'm an incredible well-designed piece of software...." :)
Laurent
On Tue, Feb 15, 2011 at 7:03 PM, Gary Chambers <[hidden email]> wrote:
|
On 15.02.2011, at 19:08, laurent laffont wrote: I hope one day we will have a comment like "I rock. I do wonderful things you never dream of. I'm an incredible well-designed piece of software...." :)But that is a contradiction in itself. How can it rock if the comment sucks? :) Norbert
|
lol
this is really geek culture > >> I hope one day we will have a comment like "I rock. I do wonderful things you never dream of. I'm an incredible well-designed piece of software...." :) >> > But that is a contradiction in itself. How can it rock if the comment sucks? :) > > Norbert |
In reply to this post by laurent laffont
On Feb 15, 2011, at 7:08 PM, laurent laffont wrote: > I hope one day we will have a comment like "I rock. I do wonderful things you never dream of. I'm an incredible well-designed piece of software...." :) Soon everyday we work on it. Stef |
In reply to this post by Gary Chambers-4
On 15 February 2011 19:03, Gary Chambers <[hidden email]> wrote:
> "Essentially useless in its current form. Probably intended to eventually > deal with actual objects in the list rather than indexing/string-forms." every time i looking at those pluggableXYZ. and it always one thought don't let me rest: - we don't need them. They are implementing/perverting functionality of base widgets. Because for most of them, they addding no value comparing to base widgets, but just some extended interface(s) on top. > Regards, Gary > -- Best regards, Igor Stasenko AKA sig. |
I would love that you show me that. I will ask alain to show me that too.
I want to learn that and we fix them. Stef > On 15 February 2011 19:03, Gary Chambers <[hidden email]> wrote: >> "Essentially useless in its current form. Probably intended to eventually >> deal with actual objects in the list rather than indexing/string-forms." > > > every time i looking at those pluggableXYZ. and it always one thought > don't let me rest: > - we don't need them. > > They are implementing/perverting functionality of base widgets. > Because for most of them, they addding no value comparing > to base widgets, but just some extended interface(s) on top. > > >> Regards, Gary >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
On 15 February 2011 21:12, Stéphane Ducasse <[hidden email]> wrote:
> I would love that you show me that. I will ask alain to show me that too. > I want to learn that and we fix them. > most of them are just adding indirection to some state and/or behavior. At cost of adding a lot of extra ivars. In general there is a quite visible pattern: every time people think that it's cool to make some morph's properties customizable, they adding ivar + accessors to PluggableXXX morphs. And since there is virtually no limits of how many "useful" new or custom properties could be added to widgets, the tendency of growth of these things to some horrid mosters become higher and higher. So, the question arises: should we rethink the model instead? And think towards adding extra/fresh properties to existing class(es) instead of making subclass with weird names which look like a piece of junk. > Stef > > > >> On 15 February 2011 19:03, Gary Chambers <[hidden email]> wrote: >>> "Essentially useless in its current form. Probably intended to eventually >>> deal with actual objects in the list rather than indexing/string-forms." >> >> >> every time i looking at those pluggableXYZ. and it always one thought >> don't let me rest: >> - we don't need them. >> >> They are implementing/perverting functionality of base widgets. >> Because for most of them, they addding no value comparing >> to base widgets, but just some extended interface(s) on top. >> >> >>> Regards, Gary >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Igor Stasenko
2011/2/15 Igor Stasenko <[hidden email]>:
> On 15 February 2011 19:03, Gary Chambers <[hidden email]> wrote: >> "Essentially useless in its current form. Probably intended to eventually >> deal with actual objects in the list rather than indexing/string-forms." > > > every time i looking at those pluggableXYZ. and it always one thought > don't let me rest: > - we don't need them. > > They are implementing/perverting functionality of base widgets. > Because for most of them, they addding no value comparing > to base widgets, but just some extended interface(s) on top. > Totally agree with Igor. Looking at the name, it already smells like a case of composition by inheritance. It reminds me the RWBinaryOrTextStreamWhatElse hierarchy. Maybe it has some cousins like PluggableMultipleSelectionListMorphByItem PluggableTreeMorphByItem etc... ;) If Pluggability is a noble feature for a GUI to have, maybe there is no much reason to carry a HardcodedListMorphByItem... Nicolas > >> Regards, Gary >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
On 15 February 2011 22:24, Nicolas Cellier
<[hidden email]> wrote: > 2011/2/15 Igor Stasenko <[hidden email]>: >> On 15 February 2011 19:03, Gary Chambers <[hidden email]> wrote: >>> "Essentially useless in its current form. Probably intended to eventually >>> deal with actual objects in the list rather than indexing/string-forms." >> >> >> every time i looking at those pluggableXYZ. and it always one thought >> don't let me rest: >> - we don't need them. >> >> They are implementing/perverting functionality of base widgets. >> Because for most of them, they addding no value comparing >> to base widgets, but just some extended interface(s) on top. >> > > Totally agree with Igor. Looking at the name, it already smells like a > case of composition by inheritance. > It reminds me the RWBinaryOrTextStreamWhatElse hierarchy. > > Maybe it has some cousins like > PluggableMultipleSelectionListMorphByItem PluggableTreeMorphByItem > etc... ;) > If Pluggability is a noble feature for a GUI to have, maybe there is > no much reason to carry a HardcodedListMorphByItem... Yeah... no tools using ListMorph. Everyone using PluggableListMorph and its variants.. So, why just not merge all stuf to ListMorph? > > Nicolas > >> >>> Regards, Gary >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Gary Chambers-4
Gary you won. Laurent On Tue, Feb 15, 2011 at 7:03 PM, Gary Chambers <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |