RE: [cfobjects-developers] Super Object vs. instance properties

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Yeah, send it to me please. I'd like to take a look at it.

>From: "Ben Bloodworth" <be...@el...>
>To: "Steven Brownlee" <or...@ms...>
>Subject: RE: [cfobjects-developers] Super Object vs. instance properties
>Date: Fri, 1 Mar 2002 16:02:30 -0500
>
>It doesn't force object to be the parent.  If a superclass key is
>identified or .notation is used, it overrides object as parent.  Object
>becomes the parent by default, if nothing is specified. The class is
>applied to the copy of the object class, not the other way around.  This
>new class is then saved back to the class registry under the appropriate
>name.  Object will never have more keys than what is specified in the
>object class file and other classes will have all of the keys of the
>object class plus any that they define.
>
>While using .notation is nice for defining parents on the fly, I also
>like being able to specify the parent in one spot, so that I don't have
>to specify it every time.  Also, if I decide to change inheritance of
>classes I can change it in one spot and it applies it everywhere.
>
>What probably will work best is supporting both options.  It's
>definitely useful to be able to specify things on the fly.
>
>Do you want me to send you what I have done for reference purposes?
>
>-----Original Message-----
>From: Steven Brownlee [mailto:or...@ms...]
>Sent: Friday, March 01, 2002 3:30 PM
>To: cfo...@li...
>Subject: RE: [cfobjects-developers] Super Object vs. instance properties
>
>
>Ah, I get it now.  I thought all keys would get inserted into the Object
>
>class registration, but now I see that you are copying it and applying
>the
>copy to the class.
>
>The only thing that I still don't like is the forcing of Object to be
>the
>parent and superClass of the class being registered. To me, it just
>seems
>counterproductive to have developers set the superClass of each class in
>the
>definition file when we can have the framework do it for them by
>default.
>In addition, I think it helps non-OOP developers learn how setting up
>their
>directory structure can mimic inheritance.  My goal is to make cfObjects
>as
>easy to learn and as quick to implement as possible.  The less code the
>better.
>
>That all said, I think you came up with a very innovative implementation
>of
>cfObjects - which is whole point.  All ideas lead to making the
>framework
>better.
>
>Now that I consider it more, I think there's a way to combine what you
>have
>done into the current tag functionality.  With the 3.0.6.2 patch I
>uploaded,
>there's an undocumented feature where you can specify implemented
>classes on
>the fly without needing to specify them in the class definition file.
>
><cf_cfoCreateObject class="Class" implements="ParentClass,OtherClass">
>
>By doing it this way, you eliminate the need for any code in the class
>definition file altogether.  I can also have cfoRegisterClass override
>the
>parent key when the structure is copied.
>
>Let me play around with it and let you know what I come up with.  We can
>try
>to find a best-of-breed implementeation.
>
>
> >From: "Ben Bloodworth" <be...@el...>
> >To: "Steven Brownlee" <or...@ms...>
> >Subject: RE: [cfobjects-developers] Super Object vs. instance
>properties
> >Date: Fri, 1 Mar 2002 14:25:15 -0500
> >
> >Steven:
> >I'll post some code snippets and hopefully things will be clearer:
> >
> >First the class.cfm for the object class:
> >stClassDef				= structNew();
> >stClassDef.className	= "Object";
> >stClassDef.superclass	= "Object";
> >stClassDef.parent 		= "Object";
> >stClassDef.lib			= trim(lib);
> >stClassDef.methods 		= StructNew();
> >stClassDef.implements	= ArrayNew(1);
> >
> >These were keys, with the exception of implements, that all classes
>were
> >getting from cfoRegisterClass and set in the cfoClassRegistry variable.
> >All I did was change where these keys are generated and when they are
> >available to the framework.
> >
> >In the current version, in every class.cfm file you have to include the
> >line:
> >
> >stClassDef = StructNew();
> >
> >In my version this is eliminated for all class.cfm files except for
> >object.
> >
> >In the current version, if you want to implement another classes
> >methods, you have to add the line:
> >
> >stClassDef.implements	= ArrayNew(1);
> >
> >In my version the need for this is eliminated.  You can start adding to
> >the array the objects you want to implement. For Example:
> >
> >stClassDef.implements[1] = "aClass";
> >
> >In cfoRegisterClass, before it tries searching for the class.cfm file
>of
> >the object it is trying to create, it checks to see if the object class
> >has already been registered.  If it has, it makes a copy of it. When it
> >does find the class.cfm for the current class, all keys defined in the
> >class.cfm file override the keys defined in the copy of object.
> >
> >A sample class.cfm using my version could look like this:
> >
> ><cfscript>
> >stClassDef.className = "aClass"; // this is still optional.
> >stClassDef.implements[1] = "SomeOtherClass";
> >stClassDef.superclass = "aParentClass"; // optional. if not defined,
>set
> >to object
> ></cfscript>
> >
> >In functionality, it's not really any different than what you have now.
> >The same events happen, just in different places.  It offers the
>benefit
> >of eliminating two lines from the class.cfm and easier expansion if you
> >decide to add a key that expands the framework.  You could add the key
> >to object's class.cfm and it would be available to all objects, instead
> >of having to edit cfoRegisterClass.  It would also be available before
> >the class.cfm was included.
> >
> >The cfsetting is more of a minor thing.  I moved the cfsetting tags to
> >wrap the whole call so that nothing is output without cfoutput, except
> >for method code.  There were areas where things were not being caught
>by
> >either cfsilent or cfsetting.
> >
> >Hopefully, this helps clear things up a little.
> >-----Original Message-----
> >From: Steven Brownlee [mailto:or...@ms...]
> >Sent: Friday, March 01, 2002 10:56 AM
> >To: cfo...@li...
> >Subject: [cfobjects-developers] Super Object vs. instance properties
> >
> >
> >Ben:
> >
> >Why would you want to have all keys inherited by all objects?  Let me
> >know
> >if I'm reading that wrong.  You state "You can add new keys to the
> >object
> >class that you want all objects to inherit, instead of having to add
> >them to
> >the cfoCreateObject tag."  These are properties of the object, not keys
> >of
> >the class, so I'm confused about what you actually mean.  If you take
> >all
> >object-scope properties and assign them to the object class instead,
> >then
> >you remove the distinctiveness of all objects.  Again, let me know if
> >I'm
> >off base here on what you're saying.
> >
> >Also, the reason that I made the changes in 3.x was so that the class'
> >namespace would dictate what its parent was - unless overriden. This
> >makes
> >the framework much more OO compliant IMO.  It already makes object the
> >oldest grandparent of every class, so I'm not sure what benefit your
> >change
> >provides by forcing object to be the parent of every class.
> >
> >I think I'm confused about what you've done.  Could you provide some
> >code
> >examples and the benefits?
> >
> >Lastly, the <cfsetting> tag doesn't really remove a whole lot of white
> >space.  <cfsilent> seemed to do a much better job.  At least with the
> >tests
> >I did.
> >
> >Thanks in advance.
> >
> >- Steve
> >
> >-----Original Message-----
> >From: Ben Bloodworth [mailto:be...@el...]
> >Sent: Friday, March 01, 2002 8:09 AM
> >To: web...@or...
> >Subject: RE: The cfobjects website is down
> >
> >
> >Steven,
> >I didn't know there was such a thing, so please subscribe me.
> >
> >I have some updates to the 3.0.6 release if you like me to send them to
> >you.
> >   I'll highlight the changes I made below.
> >
> >Most of the keys that were assigned to a class during the register
>class
> >
> >call have been moved to the class definition for the object class.
> >
> >When cfoRegisterClass is called, it first checks to see if the object
> >class
> >has already been registered. If it has been registered it creates a
>copy
> >of
> >it and then keys from the class that is to be registered are copied
>into
> >it.
> >   If object isn't registered, it registers it first and then continues
> >registering the class it was on.
> >
> >The combination of these two changes does a couple of things.  You can
> >add
> >new keys to the object class that you want all objects to inherit,
> >instead
> >of having to add them to the cfoCreateObject tag.  It also removed the
> >need
> >to specify stClassDef = StructNew() in all class.cfm files.  In fact,
> >unless
> >that line is removed, it won't work.
> >
> >I made object's superclass object and put in a check when registering
> >classes to stop registering a class if the superclass is the same as
>the
> >
> >class.  When combined with the change above, all classes will have
> >object as
> >their superclass unless superclass is overridden in the class.cfm file.
> >
> >I removed cfoutput call from the method include lines in
> >cfoInvokeMethod.
> >That should help speed things up.  I removed all references to cfsilent
> >and
> >instead wrapped the cfoTags in cfsetting enablecfoutputonly=yes, which
> >cuts
> >way back on whitespace.
> >-----Original Message-----
> >From: Steven Brownlee [mailto:web...@or...]
> >Sent: Thursday, February 28, 2002 5:02 PM
> >To: Ben Bloodworth
> >Subject: RE: The cfobjects website is down
> >
> >
> >Ben I passed this message along.  Also, would like to be subscribed to
> >the
> >cfobjects-developers mailing list?
> >-----Original Message-----
> >From: Ben Bloodworth [mailto:be...@el...]
> >Sent: Thursday, February 28, 2002 3:57 PM
> >To: web...@or...
> >Subject: The cfobjects website is down
> >
> >
> >To whom it concerns,
> >
> >I have been unable to reach the cfobjects website all week.  If you
>have
> >any
> >control over the cfobjects website, please check into why it is not
> >responding.
> >
> >
> >Benjamin Bloodworth
> >Advanced Certified ColdFusion 5.0 Developer
> >ElectroNet - 850.222.0229
> >
> >
> >_________________________________________________________________
> >Chat with friends online, try MSN Messenger: http://messenger.msn.com
> >
> >
> >_______________________________________________
> >cfobjects-developers mailing list
> >cfo...@li...
> >https://lists.sourceforge.net/lists/listinfo/cfobjects-developers
>
>
>
>
>_________________________________________________________________
>Join the world's largest e-mail service with MSN Hotmail.
>http://www.hotmail.com
>
>
>_______________________________________________
>cfobjects-developers mailing list
>cfo...@li...
>https://lists.sourceforge.net/lists/listinfo/cfobjects-developers

_________________________________________________________________
Join the worlds largest e-mail service with MSN Hotmail. 
http://www.hotmail.com