Subject: Re: Encapsulation (you can get pills for it now)

From: Andrew Wilson <[email-masked]>
Date: Sun, 21 Nov 1993 14:44:20 -0800

Mmm,

	some general thoughts and a few opinions on encapsulation.

o	MOO hasn't got it, but for the most part this doesn't matter because
	you really can mess with property access rights to protect an object's
	implementation from prying eyes and from possible misuse.

	Noone in their right mind would prefer:

		#foo.prop = value

	over

		#foo:set_prop(value)

	The possiblility for unchecked abuse is too great.  It makes sense to
	provide 'getters and setters' rather than relying on other objects
	to assign the correct values to properties etc.

	I'm sure we've all seen code like:

		@program #foo:set_name
		name = args[1];
		if (typeof(name) != STR)
			return E_TYPE;
		endif;
		this.name = name;
		.

	there is no excuse for not using such mechanisms.

o	An object model should not be confused with a permissions system and
	should, as much as is possible be divorced from considerations of the
	design of any language which will be used to manipulate it.  In his
	frankly excellent post [Notes on changing complex software systems]
	Christopher Landauer ([email-masked]) hinted at what I believe to be the
	the the real problem which should be addressed.

	The MOO programming system will have to evolve or it will die, or
	at the very least become obsoleted by a succession of similar
	systems which are currently being developed.  The advantages
	offered by the new systems over those of MOO are primarily a result
	of the extended programming language syntax (multiple inheritance,
	formal encapsulation) and platform-friendly server implementations
        (disk basing).  MOO loses out because it is older and because its
	user-base has presented its designers with too much inertia to be able
	to make fundamental design changes.

o	Encapsulation is really a syntactic 'armour' designed to sit on top
	of an unprotected object server.  No matter how permissive the underlying
	object model may be, ideally it should be designed without ANY regard
	for security considerations, it can be ably protected by a well designed
	access language which itself makes use of underlying object-oriented
	language primatives.  MOO's permissions system is largely implemented
	in-server, ColdMud's is largely implemented in-core with a single $sys
	object, analagous to #0, providing the only real interface between
	the core permissions system (whatever form the core designers choose
	it to be) and the underlying server.

o	Rather than adopt the position of MOO as a glorified backend to the MOO
	language (surely the most complex wordprocessor ever devised), I
	believe that MOO should grow apart from the MOO language and its
	associated permissions system.  The package as it exists now might
	evolve into two distinct parts:

	o	a permissive object server with its own set of object access
		primitives which may be used by any higher-level language

	o	a programming language, like the one we use now, which
		enforces the current MOO permission system mind-set

o	I use UNIX, but I'm not tied to any one programming language to
	solve problems.  Tools as distinct as C and Prolog are able to
	co-habit a UNIX environment without complaint, and I think that
	the same should be true if you consider MOO as a platform instead
	of just the embodyment of a single language.

o	MOO can have encapsulation, MOO can have anything it wants but first
	it has to grow up and ditch a second class language.

o	Of course if MOO ever does evolve enough to go it alone then one day its 
	users will be able to take a text-dump of an existing ColdMUD database,
	design an access language with the same expressive powers as C--, and
	port the whole lot onto MOO.

This is a smiley -> ;) <-  Ok?

Andy (Networker).

ps.	Just for the record, C-- 'aint all that hot either.  Just so's you know.
	A.

---

From: Pavel Curtis <[email-masked]>
Date: Mon, 22 Nov 1993 10:07:37 -0800

> Date: Sun, 21 Nov 1993 14:44:20 -0800
> From: Andrew Wilson <[email-masked]>
> 
>       systems which are currently being developed.

I think it clear that MOO will eventually die.  It is clearly wrong-headed in
many ways when you consider such notions as scaling to globally distributed
seamless systems, and I think it would be a mistake to attempt to evolve this
language to address such goals.  MOO is not a sufficiently simple or flexible
basis for such an evolution.

>       The advantages offered by the new systems over those of MOO are
>       primarily a result of the extended programming language syntax
>       (multiple inheritance, formal encapsulation) and platform-friendly
>       server implementations (disk basing).

I do not believe that any of the currently available or announced systems is
going to be a particularly important successor to MOO precisely because they do
not sufficiently well address the scaling problem.  I believe that a
fundamentally different approach is required to move significantly in this
direction.

	Pavel

---

From: Greg Hudson <[email-masked]>
Date: Mon, 22 Nov 1993 20:17:12 -0800

> I do not believe that any of the currently available or announced
> systems is going to be a particularly important successor to MOO
> precisely because they do not sufficiently well address the scaling
> problem.

While it's certainly the case that I haven't seen any announcement of
a server which had globally distributed seamless systems in mind
(except, perhaps, Unter, which wasn't really seamless), I question
that this is the only direction in which muds can go.

I may seem stunningly small-minded in saying thiat, but I don't think
that integration and distributed systems are really that much of an
improvement over the status quo of small niche systems.  In fact, I am
quite suspicious of the viability of systems like LambdaMOO: in
addition to being a much harder technical problem than the small
backyard MUD, such systems tend to be socially incohesive and seem
less dispensable to their users.

I am much more interested in muds as programming environments.  As
programming environments go, they are a fantastically difficult
problem, even without the constraints of global seamless
distributability: a programmable mud system must be completely
dynamic, must deal with multiple people working on it at the same
time, must deal with limited resources, and must deal with untrusted
programmers.  The problem is largely unsolved and probably unsolvable,
but working on it yields considerable insight into simpler real-world
problems.

Even in such a limited, niche world, I think MOO is a long way from
perfection, and deserves a successor.  There are several candidates
with varying degrees of potential; I think they all deserve a look.

--GBH