Question - super on middleclass

General discussion about LÖVE, Lua, game development, puns, and unicorns.

What should I do with super?

1. Keep it like it is now. Performance isn't that important.
0
No votes
2. Use the debug.getinfo-based solution, even if it is a bit "hacky".
0
No votes
3. Move it to a middleclass.extras
0
No votes
4. SuperClass.method(self) is fine. Ditch super.
9
100%
 
Total votes: 9

User avatar
Robin
The Omniscient
Posts: 6506
Joined: Fri Feb 20, 2009 4:29 pm
Location: The Netherlands
Contact:

Re: Question - super on middleclass

Post by Robin »

BlackBulletIV wrote:The only problem with using SuperClass.method is that it's hard coded to the super class' name. Of course if you changed the super class, then you could easily do a find/replace, and using methods from a super class is somewhat hard coded anyway. But if hard coding the name was a problem, you could use self.super (like you were suggesting before kikito), however I'm not really sure about that syntax (doesn't sit well).
You'll have to explicitly state the superclass anyway (when subclassing), so you'll have to do a search/replace every time you renamed a superclass anyway.
Help us help you: attach a .love.
User avatar
leiradel
Party member
Posts: 184
Joined: Thu Mar 11, 2010 3:40 am
Location: Lisbon, Portugal

Re: Question - super on middleclass

Post by leiradel »

kikito wrote:There are mixins.
Yeah, I thought I could implement some things I had in mind using mixins, but when I started to write the code I realized they couldn't do what I wanted (please correct me if I'm wrong). In your example, how could I have different implementations of "fly" for different animals?

I could do what I wanted with interfaces if I was using Java. I ended up expanding an old OO implementation for Lua I had lying around with abstract methods so I could do:

Code: Select all

HasWings = class() -- class names are looked up for in the global table.

HasWings.fly = abstract() -- if an abstract method is called it raises a runtime error with both the class and the method name.

Bee = class( Insect, HasWings ) -- MI, but HasWings is more like a Java interface

function Bee:fly() -- implement the "interface" method
  print( 'Bzzz Bzzz Bzzz I am a ' .. self:getClassName() )
end
kikito wrote:it's not possible to do multiple inheritance with middleclass; (snip) I doubt it will change.
Sad, I started to use middleclass because I think everyone should be using the same OO implementation when coding for LÖVE to improve interoperability between snippets/code/modules and it seems middleclass is the most popular but I had to switch to another one that is a better fit to my problems (or would it be mindset?)

Cheers,

Andre
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: Question - super on middleclass

Post by kikito »

leiradel wrote: Yeah, I thought I could implement some things I had in mind using mixins, but when I started to write the code I realized they couldn't do what I wanted (please correct me if I'm wrong). In your example, how could I have different implementations of "fly" for different animals?
Mixins are like interfaces, but better; they come "filled in" with a "default implementation". But you can still change them.

Your code with mixins would look like this.

Code: Select all

Bee = class( Insect ):includes(HasWings) -- This adds a default fly implementation to Bee

function Bee:fly() -- this re-defines fly for Bee
  print( 'Bzzz Bzzz Bzzz I am a ' .. self:getClassName() )
end
On this particular case, we're redefining the mixin completely, since it only has one function. It is still useful to include it, since includes(HasWings, Bee) will return true; this allows making things a bit more semantic later on (if includes(HasWings, class) then ... ).

If you need more help, let's open another thread, so this one stays on topic.
better fit to my problems (or would it be mindset?)
It's definitively a mindset thing. Coming from Java, you are naturally used to classes being "closed down" and things having to be declared "in advance" (as with interfaces).

Lua's different: No compile-time type checking, & a lots of things done on runtime. It requires a little effort to get used to it, but once you get over the "I'm going to get lots of errors!" feeling, you will realize it is actually very pleasant to use.

Lua doesn't "protect you from yourself" (some people would call that treating you like an adult) but that's an advantage.
When I write def I mean function.
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: Question - super on middleclass

Post by kikito »

BlackBulletIV wrote:The only problem with using SuperClass.method is that it's hard coded to the super class' name. Of course if you changed the super class, then you could easily do a find/replace, and using methods from a super class is somewhat hard coded anyway. But if hard coding the name was a problem, you could use self.super (like you were suggesting before kikito), however I'm not really sure about that syntax (doesn't sit well).
I realized some days ago the self.super boat would not float well.

You see, 'super' changes depending on what method you are on. It's independent from the instance you are sending to it.

When I realized this, I started looking for a way to 'keep track' of the 'current function', but that's only possible with debug.getinfo AFAIK.
When I write def I mean function.
User avatar
TechnoCat
Inner party member
Posts: 1612
Joined: Thu Jul 30, 2009 12:31 am
Location: Milwaukee, WI
Contact:

Re: Question - super on middleclass

Post by TechnoCat »

kikito wrote:When I realized this, I started looking for a way to 'keep track' of the 'current function', but that's only possible with debug.getinfo AFAIK.
I'm currently using seLOVE and debug doesn't exist.
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: Question - super on middleclass

Post by kikito »

TechnoCat wrote:I'm currently using seLOVE and debug doesn't exist.
So, that definitively rules out #2. Thanks for commenting!
When I write def I mean function.
User avatar
BlackBulletIV
Inner party member
Posts: 1261
Joined: Wed Dec 29, 2010 8:19 pm
Location: Queensland, Australia
Contact:

Re: Question - super on middleclass

Post by BlackBulletIV »

Robin wrote:
BlackBulletIV wrote:The only problem with using SuperClass.method is that it's hard coded to the super class' name. Of course if you changed the super class, then you could easily do a find/replace, and using methods from a super class is somewhat hard coded anyway. But if hard coding the name was a problem, you could use self.super (like you were suggesting before kikito), however I'm not really sure about that syntax (doesn't sit well).
You'll have to explicitly state the superclass anyway (when subclassing), so you'll have to do a search/replace every time you renamed a superclass anyway.
No I actually meant changing the super class of the sub class, not changing the super class' name.
kikito wrote:the "I'm going to get lots of errors!" feeling
Ha ha, I get that all the time... especially with C++.
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: Question - super on middleclass

Post by kikito »

I just finished removing super from middleclass and middleclass-extras.

From now on, you will have to use the Python syntax for invoking superclass methods.

Thanks a lot for the feedback!
When I write def I mean function.
Post Reply

Who is online

Users browsing this forum: Amazon [Bot], Google [Bot] and 10 guests