[Prev][Next][Index][Thread]
Re: Dylan, MOP, object/relational mapping...
Rob Myers wrote:
>
> Is this a behaviour of Objective-C or of ProjectBuilder (the RAD IDE that
> WebObjects uses)? I'd expect ProjectBuilder to be building the classes with the
> accessor methods in for you the way it generates everything else, so this is
> probably an IDE/environment feature rather than a language one.
No, you can have PB generate skeleton code for you which includes
accessor functions that you can then fill in. But you do not have to do
this for "plain" access, only when you wish to create a derived class
with custom behavior. If you just map an entity to EOGenericRecord, then
it automagically gets (or fakes if you will) accessor methods for all
its attributes without any such code being written.
I could be mistaken. But that's what I got from the docs and my playing
around.
In general, ProjectBuilder and the frameworks it uses are orders of
magnitude cleaner and better designed than most other "RAD IDE" tools.
It really separates model from UI, and it really is mostly driven by the
model and metadata, and it really has almost no dependence on code
generation, really ;-) To put it another way, it's about the only RAD
tool I've seen that, out of the box, rises above the level of "nasty" on
my quality scale!
> That said, there's probably a couple of strong ways of doing this in Dylan.
> You should look at the (iteration) protocol section of the DRM: collections
> define collections of methods used in their manipulation, so you could have a
> function that analyzes the metadata on a record and generates accessor functions
> at runtime then pops them into a hashtable (or other collection). You can then
> replace them with customized versions as needed (wrapping the original methods
> in your code).
OK, generating ALL accessors in a standard way from metadata, and
allowing for them to be overriden for custom behavior is an alternative
I hadn't thought of.
> Along with, or rather than this, you can macro up accessors by name/field, and
> pass in custom code as part of the macro. No custom code, no custom behaviour.
Yeah, the approach I was trying to think through didn't (at first)
involve custom macros. But using macros opens up a whole load of
possibilites, which I haven't thought through.
Maybe in addition to describing EOGenericRecord behavior, I should have
made my desiderata and their rankings explicit:
1) I _require_ that a solution not involve any per-entity class or code
(whether or not auto-generated) for plain access to entity attributes.
2) I _require_ that this automagically provided access take a syntactic
form identical to that for custom-coded accessors.
3) I would really really really like those accessors to take the
syntactic form identical to regular slot access.
4) It would be nice if the custom classes and accessors were defined
using normal syntax. But it would only be a very minor flaw if these
classes and accessors required special syntax (a special define macro)
for their definitions.
The first is easy to get on its own; just provide a class that stores
its attributes in a dictionary and access them by key (string or
symbol). Add the second requirement and it's still not too hard, I
think; use some of the collection protocol and override as needed. The
third requirement starts to make it kind of interesting ;-) The fourth,
well...
I've digested what I've read from DRM a little more since yesterday, and
I think my original idea will not work. There are two problems, one of
which can be worked around and one of which I think is insurmountable:
1) Although you can create a new generic function and add methods to it,
it is an anonymous gf that is not bound to any name, so can't be invoked
through normal accessor syntax. I don't see a way around this.
2) There are no functions to find a class or find a generic function.
(By name. I know you can get an object's class. But this doesn't help
when you have no object yet!) This could be overcome with special macros
for defining "registered" classes and generic functions, which would do
the normal creation work and add the resulting class or gf to a
dictionary keyed by name. Then for custom classes and custom accessors,
a slightly different defintion syntax would be used.
Given those problems, maybe it's back to hacking into the error
handling... Yuck!!
Follow-Ups: