Posted by
Esteban A. Maringolo-2 on
Jan 13, 2005; 12:42pm
URL: https://forum.world.st/become-and-oneWayBecome-tp3372645p3372661.html
Hi Chris,
Chris Uppal escribió:
> Esteban A. Maringolo wrote:
>>That wouldn't be a problem, indeed i want to loose that object.
>>Because it will be used only once, once a message has been send to
>>it, it will transform (become) into another object or to nil*.
> If you are using proxies, then I don't think that using nil to mean "there was
> no data" is a very good design (even if you could implement it).
> It means that
> client code will suddenly see an object (the proxy) that they legitimately
> expect to respond to one protocol (the protocol understood by the "real"
> objects) change into a different object that responds to a completely different
> protocol. That would (at least) make the client code very complicated.
Well... actually they're not proxies, They're "stubs" (i don't know
if there is a lot of semantic difference).
The system is a OR Persistence framework i'm building for an app,
which maps attributes (i.v.) to columns in direct mappings, or to
other tables, or to 1-to-n, etc.
Let's say you have anAddress, this address has a "location" (a
City). When the broker read the definition for reads the definition
of the object, it knows (by that attribute mapping) which class of
object should go there (in the "location" i.v., say... location).
It creates a stub (anORPStub), which has the class of the (future)
object, hereafter the subject, and the key object to read it (let's
say, it's Id, Code, etc).
Once anORPStub receives a message (which should go to it's subject)
it will lookup in the session object registry (a kind of cache)
using it class and key, if the session doesn't find it in it's cache
it will lookup in the storage (SQL by now), if doesn't exists, it
will answer nil, or the object (new or cached). The stub will become
(oneWay) the object answered.
This has the flexibility of a lazy initialization of everything
which is not a String, Number, Date or any other "simple" not
relational data type in the Table. Which never comes recursive,
because if objectA refers to objectB the flow will be:
1. Read, instance and cache objectA from the DB
2. Create objectB's stub in objectA.
3. Once objectB receives any message, it will instance, and cache,
and create objectA stub.
4. because objectA already is in the smalltalk (cached), objectA
stub will become the real object, and the recursion gets solved.
> I suggest you consider using an explicit "No Data" object -- an object that
> "knows" that it represents a gap in the data, but which responds sensibly to
> the normal protocol. E.g. you'd have Customer objects that know their #name
> and which answer false to #isBlank, and BlankCustomer objects that answer nil
> to #name and true to #isBlank. And you'd have CustomerProxy objects that would
> turn (magically) into a Customer or into a BlankCustomer.
Yes... i tend to have a "virtual nothing" in almost everything, an
object that is to my domain as nil is to smalltalk. But as continue
learning, i'm not reinforcing that approach.
>>Is possible to make a trick to speed up the proccess of
>>#oneWayBecome: using a combination of #becomes:'s... or similar
> I don't believe so. And if there was, surely Blair would be using the trick
> to speed up #oneWayBecome: in the VM already ;-)
Of course, my suggestion was ingenuous, but one never knows... :-)
> I'm not sure if this is an actual /proof/ that you can't implement
> #oneWayBecome: with #become: (and some temporary objects too, perhaps), but it
> sounds persuasive to me:
> Since #become: never decreases the number of object
> references in existence, and creating temporary objects can only increase the
> number of references, it seems to follow that they can't be used to implement
> #oneWayBecome: since that /decreases/ the number of references by one.
Of course, become maintains the entropy at the same level, not
adding anything, just swapping. oneWayBecome, on the other hand,
will redirect refences.
Thanks in advance.
--
Esteban A. Maringolo
[hidden email]