Re: Joy of this, Joy of that

On Sun, 24 Nov 2024 21:19:51 +0000, Pancho wrote:

On 11/24/24 00:31, Lawrence D'Oliveiro wrote:

>
On Sat, 23 Nov 2024 23:48:59 +0000, Pancho wrote:
 

To be honest, I don't have an idea what classes not being the
implementers of instance behaviour means. Where is instance behaviour
implemented?

 
From further up: “A behavior is the set of methods used by an object
to respond to messages”. Since a class itself has no such “behavior”,
it doesn’t need to be an instance of anything, unlike Python.
 

What?, Classes do have methods, e.g. they should handle a "new" message
to create a new instance object of that class.

Looking again at that draft spec, “new” is handled as a special case.
If you look at the syntax for a class definition, the initializer
(section 3.4.3) is not defined as a method that handles a message
named “new”, it is just an unnamed block.

This is quite different from Python, where “__new__” is a classmethod,
and you can customize class-instantiation behaviour by defining a
custom method by that name.

This on top of the extra possibilities afforded by metaclasses.
Metaclasses are classes (and hence objects) in their own right, and
have their own method/member definitions.

The fact that a compiler/interpreter might handle (implementation
detail) all class behaviour, as it does in C++, doesn't matter. It is
helpful to think of classes as objects in their own right.

Not really. Consider C++, where templates are handled in a separate
language that only exists at compile time, separate from the regular
language code that executes at run time.

In Python, there is no separate language for generics, since classes
(and functions) are objects, and all object construction happens at
run time.

(Code is generated at compile time, of course; but an object consists
of data as well as a pointer to shared code, and the data is
constructed at run time.)

Yeah, we discussed this in the past. I'm totally unconvinced of the
desirability of complex multiple inheritance linearization.

 
It is useful, for example, for creating enumerations of fixed instances
of some particular base class. You inherit from both your particular
base class as well as the generic “enum.Enum” base class, to get
suitable properties of both.
 

Like an interface, IEnumerable (Chsarp), Iterable(Java)? or are you back
to some special use for Enums.

Here’s one example, a decoder for MagicaVoxel files I was playing with
a while back. An enumeration for the available material properties:

    class MATT_PROPS(enum.IntEnum) :
        PLASTIC = 0
        ROUGHNESS = 1
        SPECULAR = 2
        IOR = 3
        ATTEN = 4
        POWER = 5
        GLOW = 6
        ISTOTALPOWER = 7

        @property
        def has_value(self) :
            return \
                self != type(self).ISTOTALPOWER
        #end has_value

    #end MATT_PROPS

used in decoding and extraction of same:

    ...if chunk.id == b"MATT" :
        chunk.assert_no_children()
        if len(chunk.content) < 16 :
            raise Failure("MATT chunk initial too short")
        #end if
        matt_id, matt_type, matt_weight, prop_mask = struct.unpack("<IIfI", chunk.content[:16])
        props_present = set(celf.MATT_PROPS(i) for i in range(32) if 1 << i & prop_mask != 0)
        value_props = list(i for i in sorted(props_present) if i.has_value)
        if len(chunk.content) < 16 + len(value_props) * 4 :
            raise Failure("MATT chunk rest too short")
        #end if
        propvalues = struct.unpack("<" + "f" * len(value_props), chunk.content[16:])
        props = dict(zip(value_props, propvalues))
        for i in props_present :
            if not i.has_value :
                props[i] = None
            #end if
        #end for
        self.materials.append \
          (
            celf.Material
              (
                id = matt_id,
                type = celf.MATT_TYPE(matt_type),
                weight = matt_weight,
                props = props
              )
          )
    #end if