Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
Author (directly in email)
Please type the letters in the image above.

Original message

Author Sven Tietje <mail@sven-tietje.de>
Full name Sven Tietje <mail@sven-tietje.de>
Date 2006-10-04 11:11:24 PDT
Message hi alan,

don`t want any war with you - i`m a friend of clean oo design, too.
perhaps i didn`t make myself clear. of course, i prefer a single
instance of each object.

i`d like to have PropelResultset:

class PropelResultset implements IteratorAggregate, ArrayAccess {
   
}

foreach ($resultset as $row) {
    private $cache = array(
       0 => BaseObject,
       1 => BaseObject,
       .....
    )

    // the objects are generated on the fly and on demand.
    // the objects are cached
}

fetching a special element afterwards will not generator a new instance
again - will return the object generated during the first iteration.
$blah = $resultset[0] => [0] is already generated - you`ll get the
cached object back.

or you iterate the resultset again => it`s not necessary to hydrate the
objects again - its just iterated about the interal cached array
containing the object instances.

i think, that variante is the normal variant and its compatible to all
our applications.

the second variant is a none-caching variant -> not use much memory ->
eg overview, only output etc...
of course, i could use an array, but i like oo-style for fetching data.
cause of this, i proposed to use FETCH_INTO - we can do it another way.
$object->getRelatedObject() is queried on the fly, too. afterwards, data
is gone.

the first variant should still be the prefered and default variant of
handling data.

greets sven

Alan Pinstein schrieb:
> Why? Because re-using objects is:
>
> 1. BAD OO design... one instance == 1 LOGICAL instance. If you re-use
> it, you are pretty much breaking black-box. "Clients" of your objects
> don't expect this behavior, because it's bad OO design.
>
> What if in the course of using FETCH_INTO, you have some relationships:
>
> foreach (FETCH_INTO loop) {
> $myObj->setRelat​edObject($Y);
> }
>
> Well this is going to end up an awful mess, with no referential
> integrity in your object model.
>
> 2. There is no meaningful benefit to FETCH_INTO. Seriously, name one
> potential benefit of doing this. Are you thinking performance? Lots of
> things in OO would be faster if you break the OO... but it shouldn't
> be done.
>
> 3. With your example:
>
>> Now, i wanna publish a List of Person with their fullnames. I don`t
>> want to
>> change data or something -> just want to print table containting the
>> fullname and some columns additional information. I`ll implement a
>> method
>> getFullname in my Object-Class:
>
> Ok great! That's a completely reasonable thing to want to do. HOWEVER,
> I don't see why getting back DISTINCT instances for each iteration
> prevents this from happening. It doesn't use more memory and it isn't
> much slower (only real speed difference is calling the constructor).
>
> However, I can promise you that getting back the SAME instance each
> time, but it having different data for *some* columns, will definitely
> cause you hours of painful debugging, followed by "Why am I using
> FETCH_INTO"?