[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: OO - keeping lua as lua
- From: Mark Hamburg <mhamburg@...>
- Date: Tue, 25 Jan 2005 09:29:17 -0800
on 1/25/05 2:38 AM, David Given at email@example.com wrote:
> My general opinion of languages with enforced data hiding is that (a) you
> cannot stop the user being a muppet; (b) enforced data hiding is a pain from
> the programmer's point of view; (c) therefore it's far easier to simply not
> bother. Document the fields and methods as being internal, and if the user
> plays with them, that's it's problem.
I like that position until it hits the issue of having users not be the same
as the one's potentially writing code. For example, if I publish the APIs to
my system so that it can be extended by others, the consumers of such
extensions are not necessarily the authors of the extensions. I can see an
argument for wanting to protect consumers from sloppy or malicious authors.
An extension script might not work, but it would be nice if it couldn't
cause damage throughout the system.
That being said, I think Lua's syntax is fine with respect to supporting the
polymorphic aspect of object-oriented programming. Lua's support for
inheritance doesn't work as transparently as in some languages built around
inheritance, but it's usable (and I personally find inheritance over-rated).
So, solving the encapsulation problem in a simple, efficient manner is
probably my top concern to the extent that I have one.
(I've actually been spending more time thinking about how to make GC for
semi-weak tables work without having cycle problems -- though if that worked
it's one way to achieve encapsulation.)