yeah I think option b is better cause it does not "corrupt" existing code.
This way I wont have to modify existing classes to add those tags. I could
even tag group of classes or group of methods ( or protocols ).   


Igor Stasenko wrote
> there's only two practical ways (which i know and use) of associating
> extra
> state per object:
>  - internal: by extending object's state via directly adding extra
> instance
> variable (or indirectly like Morphic's properties)
>  - external: creating a map (aka dictionary) which maps between your
> domain
> object(s) and its corresponding extra state.
> 
> i do not see how classes (like any other object) is exception from that.
> 
> 
> 
> On 13 September 2013 09:40, kilon <

> [email protected]

> > wrote:
> 
>> I like to hear some more details on this and other opinions too.
>>
>> One of the thing I want to work is a new SystemBrowser with more flexible
>> browsing system. I take inspiration from preset browsers in software
>> sysnthesizers. Each preset represent a sound that can be manipulated with
>> real time controls, the problem is that there thousands of presets the
>> same
>> way there are thousands of classes. The initial implementation was to
>> brake
>> presets to groups / categories , same way SystemBrowser has packages.
>> Unfortunately that still made browsing through presets very tedious and
>> long
>> process.
>>
>> The modern system is tag based , for example if I want to select a sound
>> present I a presented with a row and columns of buttons, each row is a
>> category of tags , each cell is a tag. For example I could choose Timbre
>> :
>> metalic , Type: pad,  Speed: fast, Rythm : non-rythmic etc these
>> criterias
>> then would allow me to browse only a limited amount of presets having
>> those
>> tags. I would have to reset the browser (which disables all tag choices)
>> to
>> view all presets again.
>>
>> I am considering implementing something similar for class and even
>> methods.
>> At first I was considering what Igor said, an instance variable that
>> contained a dictionary/hash-table associating tags with their categories
>> providing also a gui to set those tags easily.  However I was wondering
>> like
>> the original poster if there is a better way to "annotate" classes and if
>> there is any way to "annotate" methods .
>>
>>
>> Esteban A. Maringolo wrote
>> > Isn't answering to a message not enough?
>> >
>> > Like #nbStruc #ormTableName etc.
>> >
>> > Pragmas are somehow orthogonal to the common message sending and method
>> > lookup.
>> >
>> >
>> > Esteban A. Maringolo
>> >
>> >
>> > 2013/9/12 Igor Stasenko <
>>
>> > siguctua@
>>
>> > >
>> >
>> >>
>> >>
>> >>
>> >> On 12 September 2013 13:56, Torsten Bergmann <
>>
>> > astares@
>>
>> > > wrote:
>> >>
>> >>> We can mark methods with pragmas and ask the pragma collector
>> >>> to give the methods marked with it.
>> >>>
>> >>> Do we (already) have some kind of pragma like mechanism to annotate
>> >>> classes? I mean a general mechanism that one can use to mark classes
>> >>> with pragmas/settings/ ...?
>> >>>
>> >>> There are various scenarios where this might be useful:
>> >>>   - an ORM mapper would like to associate a persistence class with a
>> >>> table name
>> >>>   - an NBExternalStructure subclass wrapping a structure can be
>> >>> annotated
>> >>> with
>> >>>     the original struct name
>> >>>   - ...
>> >>>
>> >>>
>> >> Why so complicated (e.g. pragmas) ? Just add one more inst var , like
>> >> 'annotation' for Class object
>> >> and you have it.
>> >>
>> >>
>> >>> Thx
>> >>> T.
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Igor Stasenko.
>> >>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Annotating-classes-tp4707854p4708033.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>
> 
> 
> -- 
> Best regards,
> Igor Stasenko.





--
View this message in context: 
http://forum.world.st/Annotating-classes-tp4707854p4708669.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Reply via email to