Berry Script: How to invoke methods of class bytes from a subclass of class bytes ?

[GEAG]

Hi

It's unclear to me how from within an object of a subclass of class bytes, the methods of class bytes can be used correctly ?

Ex:

class Sub : bytes
 def assign(aBB)
  self = aBB    # trying to assign a byte buffer aBB to the baseclass object bytes ?
 end
 def append(aBB)
  self .. aBB  # trying to append aBB to the bytes object inherited by a Sub
 end
 def getHead(headLen)
  return self[0..headLen-1)
 end
end

var bb = bytes().fromhex("AABBCC")
var sub = Sub()
sub.assign(bb)
sub.append(bb)
var head = sub.getHead(3)

I am not sure, that assigning (=) something to self or subscripts on self are working as intended?
It doesn't seem that the following would also be possible?

var head = sub[0..2]

Or should that work correctly?
How about this:

sub[0] = 0x77

Should that work too?

Thanks for your help in advance.

[s-hadinger]

self = aBB is definitely wrong. The only effect would be to change the value of the reference to self for the code below it, but won't do anything to the instance itself.

When you do a subclass, you can call any method of the superclass.

What are you trying to achieve?

[GEAG]

Since the assignment operator "=" is a legal operation on objects of class bytes, I would have expected, that it is also inherited by any subclass of class bytes, like any other method of class bytes. If a method append(aBB) would have been defined on class bytes, it would also have been inherited and could be used as self.append(aBB), unless it would have been overloaded.

If this doesn't hold to be true, it would be nice to tell everybody about those restrictions imposed on the predefined class bytes with an additional remark in the berry specs fro class bytes.

Why would I want to use a subclass of class bytes?

Because the behavior set provided by its operators & methods is useful and the alternative of having an instance var of class bytes in a regular class is more cumbersome, because many of the bytes class's methods have to redefined in that class. Inheritance would avoid this large boilerplate of additional methods needed anyway.

For ex. for network programming, one needs additional protocol specific behavior added to byte buffers. Imagine some PPP over serial or higher level application protocol packets received that need to be verified and treated or generated.

The principles of min coupling and max cohesion a few decades back proposed by Parnas and underlying today's OOT suggest to put data and behavior together where cohesion is high.

[sfromis]

No, = is not legal on objects of class bytes (or any object), but if you assign something to a variable holding a reference to a bytes (or whatever) object, you're replacing the variable to no longer have any connection to the prior value. This is not an "imposed restriction", just how variables work in Berry, irrespective of involved values happening to be objects of bytes (or other classes).

In other words, the variable is not the object, it only has a reference to the object existing on it's own, and when no references are left, it will be garbage collected. And if you assign a bytes object to variable a, assign a to variable b, and then modify the object referred to by a, you'll see that modification reflected when querying the value of b, as they refer to the same object. But if you instead of modifying a replaces the value in an assignment, they will no longer be referring to the same bytes object.

When extending a class with a subclass for additional functions, and using the same method names, you can still have your subclass use the superclass methods like super(self).clear() if you want to do some additional stuff on top of the standard operation of the clear method.

I'd not really call = an "operator", as the assignment is not involving the existing value, that is only when using derived operators like += to update the old value, including for objects having a + method.

[GEAG]

Thanks for your explanations of the Berry semantics that make sense to me. Talking about references clarifies many semantics things about Berry also that I have not been certain about (like arg passing of functions and methods by reference to the object or passing by value with an implicit copy of the object ? Even after reading the documentation multiple times. Thanks.

When extending a class with a subclass for additional functions, and using the same method names, you can still have your subclass use the superclass methods like super(self).clear() if you want to do some additional stuff on top of the standard operation of the clear method.

I think the "short berry manual" does not point out, that super() delivers the reference to the object of its baseclass, although that would have been the expected behavior to me without the documentation. But the docu rather says:

super(object): Get the super class of object. The object is a class or an instance

That's quite a different thing. From this description, I understand, that the class is returned, not the object. Therefore method clear() could not be used. Only static methods would be possible on the class level.

Is the short berry manual misleading?

But in the example of the bytes_array given below, super(self) seems to provide a reference to the class, because the constructor init() is applied to it. That would be conform to the berry docu.

[sfromis]

To illustrate a basic case of how super() works:

class a end
class b : a def init() print('b.init', self, super(self)) end end
bb = b()
b.init <instance: b()> <instance: a()>
print(super(b), super(bb))
<class: a> <instance: a()>

When the object you pass is a class, you get the super class.
When it is an object of a class, you get the instance of the super class.
The construct with super(self).method() is described in the docs.
https://berry.readthedocs.io/en/latest/source/en/Chapter-6.html#access-base-class-object

The way I see it, supported by the above test, is that the constructor init() is called as an instance method after the instance already was created, only to let instance initialization happen. Hence super(self).init() is consistent with super(self) returning an instance, and not the class object.

But yeah, the short manual is "a bit short" on the finer points.

When it comes to call by reference vs by value, objects/instances will be passed by reference, while variables with "primitive" values (not an instance of anything) are passed by value. This makes no difference to string objects, as these are immutable, but is a significant factor around mutable objects, including bytes objects.

BTW. The class reference is also "merely" a variable holding a reference to the object housing the class. Hence you can assign the variable for the class to another variable, and then use the second variable to instantiate the class, just like when using the original variable "happening" to be named after class.

This also goes for functions. Hence you can have functions be "simply" an instance variable in the object, and then assign it like self.greeter = /arg->print('hello', arg)

[s-hadinger]

the "short berry manual" does not point out, that super() delivers the reference to the object of its baseclass, although that would have been the expected behavior to me without the documentation. But the docu rather says:

super(object): Get the super class of object. The object is a class or an instance

That's quite a different thing. From this description, I understand, that the class is returned, not the object. Therefore method clear() could not be used. Only static methods would be possible on the class level.

You are right, it returns either the super class if the arg is a class, or the instance of the super class if it's an instance. What would be the correct wording?

super(self) has some special behavior:

self.f(arg)

# is equivalent to the following
var f_temp = self.f
f(self, arg)
# self is silently passed as the first argument of the method called

When you call the method of the superclass, it needs some tricks:

# let's take this call
super(self).f(arg)

# a naive implementation (and actually the original in Berry) would be
var f_temp = super(self).f
f(super(self), arg)

# But this would actually break the whole point of inheritance overloading
# since the method called has now no visibility on the potential sub-classes
# What you actually want (and what Berry does now) is
var f_temp = super(self).f
f(self, arg)

This was definitely fixed in Berry in berry-lang/berry#132

[s-hadinger]

@GEAG I suggest you read the Berry documentation avec class inheritance: https://berry.readthedocs.io/en/latest/source/en/Chapter-6.html#class-inheritance

If you want a full and non-trivial example of overloading bytes class, the bytes_array class used in energy is a good example: https://github.com/arendst/Tasmota/blob/development/lib/libesp32/berry_tasmota/src/embedded/energy.be

Finally, a more general question is whether you need inheritance or composition. The example you mention about parsing PPP traffic may be better served with composition (a class containing bytes) vs a subclass. I will let you decide.
https://en.wikipedia.org/wiki/Composition_over_inheritance

[sfromis]

While inheritance can be pretty convenient if the subclass is still supposed to be compatible with the superclass, just with additional methods, I do agree that a PPP protocol using a bytes objects internally is not a good case for inheritance.

You expose "too much" to be an API of the PPP class, making it more complex for the PPP class to always be compatible with things done outside of the intended API. Maybe it would later make sense to no longer have it "be" a bytes object.

One example where I chose to use inheritance is when playing with a "functional list" class, still to act as a normal Berry list, but adding some features on top like map/reduce/sort etc.