> Imho, there are already too many meta-models in the squeak > world, just as there are too many event frameworks. OB has one > that defines what properties a node in a tree can take on. > FileList has one that describes what actions can be done to a > file. Preferences has one. Etoys had a huge one, but let's not > even go there. > > I don't know if it belongs in the core (I don't know what the > core is), but it is a basic service I'd expect a lot of > libraries could depend on. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/
Choice is not a bad thing, there is no uber meta model that will suite everyone's needs all of the time. There's nothing wrong with projects creating their own meta model that is suited to exactly what they need. For most things, I find pragmas more than sufficient for static metadata and much lighter weight than Magritte both in code and brain power. There's also the nice synergy of having your metadata actually bound to the things they're representing. This is an advantage pragmas have over Magritte. Magritte has the advantage when the metadata starts to become dynamic but you pay for using it with a much heavier weight code centric approach that separates the metadata from what it's representing. Now you have to maintain a link between the "thing" and the "meta thing" either by either naming patterns or by using pragmas to bind them. These are serious trade-offs to make, it's certainly not a no brainer. Ramon Leon http://onsmalltalk.com _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
