Chuck Adams on Tue, 5 Dec 2006 18:26:41 -0700 (MST)

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [s-d] attributes redux

On 12/5/06, Jake Eakle <jseakle@xxxxxxxxx> wrote:
> The problem with removing scope is that now attributes have to be explicitly
> given to things, whereas before they were automatically created when a new
> object in the scope came into existence. I suppose each attribute could
> specify (in it's value? I'm a little unclear on the distinction between an
> attribute's value and the rules for determining its value in your version)
> that it gets applied to new objects, but that's annoying - much nicer to
> just say "All X's have attribute Y" and have a rule take care of keeping
> that true. Also, why not have formal names for the various aspects of an
> attribute? Of course it's not strictly necessary, but it makes them easier
> to talk about, and standardizes their formats for the purposes fo possible
> meta-rules that refer to them.

There is no need for a scope mechanism to be built into the attribute
when a rule stating that a scope exists expresses the scope for you.
All it takes is a rule that states "All current and future X's shall
have an attribute named Y, given a of Z when the attribute is created"
and it is done (and I just took care of defaults en passant too).

Granted that sentiment could be construed to leave attributes in
general completely to ad hoc mechanism, so maybe scope is called for
as an intrinsic part of attributes ... I'm just not sure, when
expressing the scope was already that concise.  It would make
"browsing" attributes a lot easier though.  What do you suggest as a
concrete representation of Scope?

The formal names already exist for name and value, and since I really
don't think anyone wants to play B Nomic with an interpreter, abstract
machine, or denotational semantics, I figured the prevailing common
sense consensus on the meanings of values should prevail over
laboriously defining a type system that's bound to be inadequate to
the task anyway.

Using an interpreter, I do like -- got my own nomic that does exactly
that.  I don't think it's what's being aimed at tho.

> I do like changing it so that any object can have attributes. I would just
> add that to the other version.

There's more to it -- there's some other provisions too that make
Attributes only creatable where allowed by rule.  But possibly that's
redundant with existing rules concerning game objects anyway.

spoon-discuss mailing list