RES: RES: Cryptic OOP syntax

[André de Leiradella <leiradella@...>]

> Dear André
Hi,

> 
> I guess it has become pretty much clear that for your users, you need
> - some form of OO-style programming facilities
> - with a not-so tedious syntax
> - supporting encapsulation ...
> - ... but with a backdoor called "protected"
> and we also saw that it can be done one way or the other.
> 
> Would you care to restate what would be your user's minimal
> requirements? 
Of course not.

> 
> Is writing "B extends A" instead of some B = class(A,...) important?
As much as writing "local function f(...)" is better than "local f; f =
function(...)". But one thing that I like is being able to define all
the class' members inside a block like

class B extends A -- or B = class(A)
	local name --[[ It's local to the instances of this class, or
private in other words. Unless we introduce keywords to make some
members public and others private, I prefer to have them all private.
It's easier to make private members "public" using getter/setter methods
than trying to hide members that should be private from the outside
world. ]]--

	--[[ If we are to have multiple constructors, maybe we'll have
to flag them in some way, maybe using "constructor" instead of
"function". ]]--
	constructor new(name)
		super.new()
		self.name = name
		--[[ Note the lack of housekeeping inside the
constructor, self already comes as an uninitialized instance of B. Note
also how to call the constructor of the super class. ]]--
	end

	function getName()
		return name
	end

	function toString()
		return self.getName()
		--[[ Returning the return value of the inherited method:
return super.toString(). ]]--
	end
end

> Writing "new B" instead of B.new? Having self.name = name in one
I can do without new, specially because I'd like to be able to have more
than one constructor for a class, and calling B.new, B.load or whatever
seems like a good way to specify the constructor.

> method, but elsewhere name magically refer to self.name? (would this
I can do without it too. I think users will make less mistakes writing
self to access member variables.

> really make life easier for your users? or would you expect
> "parameter hides member name" compiler warnings?)    
That's not needed.

I use lots of interfaces in Java, but I think they don't fit in Lua.
Instead, I'd like to have multiple inheritance and I think it goes along
the Lua lines of not limiting the programmer. How to handle methods
declared in more than one inherited class is a discussion that I can't
have right now, have to study a little first :)

I think static members are not needed, we can always have a local
variable/function outside the class. Neither abstract functions, thought
I'd use them to flag methods that must be implemented in subclasses as
we don't have interfaces. But I can implement dummy abstract methods
that will issue an error if they're called, telling the user that he/she
should have implemented the method.

Packages (I mean Java packages) aren't needed, I think classes shipped
inside packages will already be within their own namespaces.

I like the idea of having new metamethods (__inherit(class, instance,
method, ...), __new(class, constructor, ...)?) to enable each one to
implement the class system he/she sees fit for a particular problem, but
I'm afraid when you start to write a huge application in Lua with
classes coming from packages of various different writers it'll become
difficult to remember how each set of classes behave in terms of
inheritance etc. Default metamethods with well documented behaviours
will minimize that though.

Regards,

Andre