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.
