with only 2 levels of class / subclass its hard to demonstrate any difference betweeh tne sub calling super or base
but with 3 it is
my code above that passes in a typeinfo makes this much clearer
Class Base
Shared Sub DoMsgBox
MsgBox("Base")
End Sub
End Class
Class SubClass
Inherits Base
Shared Sub DoMsgBox
// These two are equivalent
Super.MsgBox()
Base.MsgBox()
End Sub
End Class
Class SubSubClass
Inherits SubClass
Shared Sub MsgBox
// but these two are are NOT equivalent <<<<<<<<<
Super.MsgBox()
Base.MsgBox()
End Sub
End Class
There are VERY few places where you want the base class to have some generic code for doing the work and NOT have to have that creation code in each subclass. I think thats the original question - “why cant AR be set up this way?”
I suppose it could be argued that Active Record is one such place this could be of use
Each subclass would then be not much more than the properties that are mapped onto a db column
Thats just NOT how the implementation of AR ARGen creates actually works (nor do I think it needs to work that way)
Yeah and now that I think about it… it is “overriding” from the developer’s point of view. From the compiler of view, it just feels like a trick to make a relationship that is really just two namespaced methods with no class hierarchy at all.
Oh they are definitely namespaced but the relationship between super class & subclass also plays into it
But, unlike normal instance method overloads, this is done by the compiler at compile time since shared methods arent dispatched dynamically as far as I know
It has to do with Factory Design and the way that we should be creating an Active Record system to create and manage instances of objects that link to a database.
Consider my Base class. It handles all the interaction with my datasource. I’ve locked it away into it’s own little module so I can drop it into any new project for easy reuse. Now, all I need to do is create a class that subclasses Base for each table in my database and without writing any new SQL, I’ve got access to my data. I can simply create a property of the type I need in my Window and start using it.
But here is what my Team class looks like currently…
Event Definitions, Event Handlers, Methods for construction and CRUD operations… and then the properties. To make this subclass, I literally have to copy and paste (or duplicate) all of this and then go back and make minor modifications as required. FOR EACH ONE!
Now imagine that I have 101 tables in my database. This gets stupid real fast.
In Python, they have a rule called, ‘DRY’. It stands for Don’t Repeat Yourself. Being able to call a super’s method directly (without having to override it in the subclass) but still have it receive a reference to the subclass, means that I can write something like this in my Window…
Team.Save
Notice that I reference Save() as if it was a method of Team… but it’s not. I’m actually calling Base.Save() but because I referenced it through Team, it knows what subclass to use… and ultimately which type of object to save/delete/return.
If Xojo had this ability my Team class (and all 100 of my other data classes) would look more like this…
Must admit Im not a database programmer but maybe you could pass a Runtime object ID of the subclass to its super from the subclass constructor to let the super get context info from your subclass when the supers saved method is called? Just a thought.
Otherwise I guess that to get a semi-compiled late-binding effect in Xojo requires using the XojoScript object (which can be fed scripts created on the fly) if the task is simple enough. Not sure of any performance hit though.
[quote=496525:@Kristin Green]…
In Python, they have a rule called, ‘DRY’. It stands for Don’t Repeat Yourself. Being able to call a super’s method directly (without having to override it in the subclass) but still have it receive a reference to the subclass, means that I can write something like this in my Window…
[/quote]
Xojo isnt python
And its language doesnt work like that
File a feature request to ask them to change the language and runtime
In the mean time the code I posted way back here is whats possible
[quote=496525:@Kristin Green]
Now, do you see why this is so important?[/quote]
the way you’ve pictured this and laid it all out Save is an INSTANCE method
Not a shared method
So “Save” can exist on Base and works as described
What WONT is the original “FindByID” which is a shared method and ha NO access to the properties of a subclass instance because none exists for a shared method
[quote=496525:@Kristin Green]Event Definitions, Event Handlers, Methods for construction and CRUD operations… and then the properties. To make this subclass, I literally have to copy and paste (or duplicate) all of this and then go back and make minor modifications as required. FOR EACH ONE!
Now imagine that I have 101 tables in my database. This gets stupid real fast.
[/quote]
Have you looked at introspection as you could get your base class to access the subclass?
For example, if you put this code into a base class method and call it from a subclass instance it will display all of the properties in the base class and subclass.
[code]Dim classProperties(-1) As Introspection.PropertyInfo
Dim i As Int32
Dim output As String
Dim propertyInfoObj As Introspection.PropertyInfo
its similar object serialization
it could map propertys to table fields or output data into a file like xml / json.
for sure a good approach to have a single class that can handle the load & save of each object.
friendly reminder - threads with generic titles like this one, or similar “Problem in Xojo” etc. are not as useful as threads with more specific titles. I care alot about Shared Methods and Properties in Xojo (but I almost skipped this thread due to the generic title). I use shared methos & properties a lot but they feel kinda half-baked - another frustrating issue is that you can’t see the value of shared proprerties in a Shared Method, unless you also have an instance to click on in the debugger.
In any case, I believe the original poster can change the thread title to make it it more relevant?
Yes. This is in fact what the ResourceName() method in my screen shot above does. (The Serialize() method also uses this but retrieves the list of properties instead.)
Protected Function ResourceName() as String
Var t As Introspection.TypeInfo = Introspection.GetType(Self)
Return t.Name
End Function
The problem is that it must be called within the subclass or else it returns the name of the Base class. This is precisely the issue.
Rather than have Base.Save() run ResourceName(), I must create a method in Team that serves no purpose other than to run ResourceName() at the subclass level.
Please prove me wrong. Shared method or not, Base will not know what a Team is unless the function is called from a method of the subclass. The goal is to not have to create a subclass method at all.
I know that it can’t be done. Hence the title of this thread. Everyone keeps trying to tell me it can’t be done, offer a work-around, or insist that it can be done because they don’t understand it.
[quote=496533:@Norman Palardy]Xojo isnt python
And its language doesnt work like that
File a feature request to ask them to change the language and runtime[/quote]
Yes. I plan to. I just wanted to ask the smartest people on this board what this functionality might be called (so that I may clearly ask for it) and if this topic had ever been brought up before so that I wouldn’t be duplicating someone else’s request. As it stands, my inability to accurately describe the issue in a way that people will understand it (see proof of that above) currently prevents me from sending feedback to Xojo.
[quote=496551:@Michael Diehr]friendly reminder - threads with generic titles like this one, or similar “Problem in Xojo” etc. are not as useful as threads with more specific titles. I care alot about Shared Methods and Properties in Xojo (but I almost skipped this thread due to the generic title). I use shared methos & properties a lot but they feel kinda half-baked - another frustrating issue is that you can’t see the value of shared proprerties in a Shared Method, unless you also have an instance to click on in the debugger.
In any case, I believe the original poster can change the thread title to make it it more relevant?[/quote]
YES! Thank you!
The reason the title is so vague is that I don’t what to call it. The point of the thread is to ask for help describing it so that I can file a meaningful feedback ticket.
So, if you can think of a better title, please provide one and I will change it.
The only thing that frustrates a Xojo Forum Member more than a vague title is a bold claim by a Noob that Xojo can’t do something. I’d apologize for the ‘click-bait’ but it kinda worked.
My apologies. You are correct. The ResourceName and Serialize methods don’t need to be included in the call to Super.Save().
When you run Team.Save() like this…
Public Sub Save()
Super.Save()
End Sub
Base.Save() can run things like Introspection.GetType(Self) and it will return the TypeInfo of the base class. But not for Shared Methods which a method such as FindByID() might require since it would be run as a class method without an instance.
The issue still remains. I have a lot of useless methods in my object class… and I don’t know what to call the object-oriented principle that would describe the feature that Python seems to have, that Xojo doesn’t, that makes this problem go away.
[quote=496563:@Kristin Green]
The issue still remains. I have a lot of useless methods in my object class… and I don’t know what to call the object-oriented principle that would describe the feature that Python seems to have, that Xojo doesn’t, that makes this problem go away.[/quote]
probably dynamic dispatch and that still would require a huge overhaul of the language & compiler
file a feature request with enough description and the specific name wont matter
and realize that such a significant change is unlikely to happen “soon” so I’d find a different way to do this
