On Apr 15, 2015, at 8:01 PM, Cameron Sanders via Pharo-users <pharo-users@lists.pharo.org> wrote: > > Sure, I am happy to share. We are to the point that we need to get people > interested in this platform; one thing we offer is a source license and > therefore we need to document things that we have not yet documented. > > So please, fire away any questions.
Are there any instances of Magritte framework that are not an instances of a custom subclass? (Did you have to subclass everything?) What pushed you toward custom subclasses? Was the properties dictionary not sufficient for extending the object state variables, or was it a speed/performance issue? Would refactoring the Magritte classes to have various hook methods allowed you to avoid making custom subclasses? (I found that it was Twitter Bootstrap which drove the need for subclassing the framework, whereas native HTML would have been adaptable to Magritte’s needs). Did you use the OneToOne and OneToMany relationship descriptions by subclassing, or did you create entirely new ones? What are some statistics on your model - e.g. number to classes? average (mean/median/mode) number of attributes/methods per class? average depth of the class hierarchy? Do you translate/map the “Smalltalk” query blocks for GemStone to get better speed, or is this unnecessary? Do you use Magritte descriptions to tag things for indexing on GemStone? Or, do you just manually create indexes on GemStone as necessary (e.g. via install code that encapsulates knowledge of where to index, or does the system automatically raise flags when indexing is needed). From various postings, I gather you have a lot of data to process. Do you have any numbers like: - total number of objects in the system - biggest collection, typical collection size Thanks for sharing your experience.
