What is a BRANDED OBJECT?
Closed this issue · 5 comments
Deleted user commented
I have read the tutorial and language definition. No where I found information about it. But reading code I encountered BRANDED OBJECT regularly. The document about OOP part is severe missing. Object is only mentioned briefly on Types section but nothing more about it mentioned. There is no mentioning of access modifiers (e.g: public, final,... on Java). The part about constructors missing many information and is confusing at least.
mikanystrom commented
What you need to read is the Green Book (Greg Nelson, ed., Systems
Programming with Modula-3, Prentice-Hall, 1991) and I mean read it
cover-to-cover.
Now, branding is covered in the section on Reference Types. So here, for
example:
https://www.cs.purdue.edu/homes/hosking/m3/reference/refs.html
In both the traced and untraced cases, the keyword REF can optionally be
preceded by "BRANDED b" where b is a text constant called the *brand*.
Brands distinguish types that would otherwise be the same; they have no
other semantic effect. All brands in a program must be distinct. If BRANDED is
present and b is absent, the implementation automatically supplies a unique
value for b. Explicit brands are useful for persistent data storage.
I am guessing Modula-3's OOP is not for everyone. It follows Einstein's
Principle: "make it as simple as possible, but no simpler".
There are no constructors in Modula-3, nor destructors. You'd implement
the former by convention (normally declare a .init() method that the
creator would call) and the latter you can implement through WeakRef if you
really want it. There's a discussion somewhere about why destructors are
possibly a bad idea: they are run when the garbage collector mops up an
object, and there's no guarantee that that ever happens, so in systems that
use GC-driven destructors, destructors are required to be semantic no-ops.
Access modifiers are accomplished through partial revelation. There are
lots of examples in the code base. The chapter in the Green Book on
readers and writers contains a real-world example. Also available as
SRC-RR-53:
http://bitsavers.trailing-edge.com/pdf/dec/tech_reports/SRC-RR-53.pdf
The basic idea is that OOP is done by establishing conventions on top of
some simple language features, not by adding a kitchen sink of partially
overlapping OOP features to the language itself. It's kind of how if you
read K&R, you won't see any mention of header files, but yet, in any
industrial environment, the way header files are used to establish
interfaces to C code is probably one of the most important aspects of the
programming experience. Now, M3 does already have interface and
implementation modules, so it does talk explicitly about that, but the way
they do OOP is similar: some simple idea (such as #include) and an
elaborate mechanism that's built by convention on top of that. Of course
if you don't like the convention, you're free to code as you please. (I
know people who put almost all executable C code in header files...)
Personally I think the design is absolutely brilliant. The day you decide
to write a program that processes Modula-3 code (in particular, interfaces)
as data, you really, really come to appreciate how simple and consistent
the language definition is.
Mika
…On Fri, Sep 9, 2022 at 8:15 PM pwd96m4a ***@***.***> wrote:
I have read the tutorial and language definition. No where I found
information about it. But reading code I encountered BRANDED OBJECT
regularly. The document about OOP part is severe missing. Object is only
mentioned briefly on Types section but nothing more about it mentioned.
There is no mentioning of access modifiers (e.g: public, final,... on
Java). The part about constructors missing many information and is
confusing at least.
—
Reply to this email directly, view it on GitHub
<#1075>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKYNJMELTAY5FNJFUQUAK3V5P4OLANCNFSM6AAAAAAQJEWU54>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
jpgpng commented
I don't know either but I found it always go together with REVEAL.
Update: sorry, I didn't see @mikanystrom's comment above.
jpgpng commented
@mikanystrom You said there is no constructors. So what is this?
mikanystrom commented
Sort of, in one direction it is true:
types that are partially REVEALed are required to be BRANDED at the point
that they are fully revealed. Else the language rules would allow the
declaration of "impostor" types, and get at the private data of an object
without passing through its declared interfaces.
You do not need to use REVEAL to use BRANDED, though, but that's what
branding is really for: to protect the privacy of data in objects that have
fields that aren't to have public access.
Mika
…On Sat, Sep 10, 2022 at 2:06 AM jpgpng ***@***.***> wrote:
I don't know either but I found it always go together with REVEAL.
—
Reply to this email directly, view it on GitHub
<#1075 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKYNJPV4VPUMHITXWAG5FLV5RFS7ANCNFSM6AAAAAAQJEWU54>
.
You are receiving this because you commented.Message ID:
***@***.***>
mikanystrom commented
Ah sorry, I meant there are no constructors in the OOP sense. There are no
methods that get run, non-optionally, when you NEW an object.
A record constructor is a way of writing a record literal in inline code.
E.g.,
TYPE T = RECORD x, y : INTEGER END;
VAR
a, b : T;
BEGIN
a.x := 0;
a.y := 1;
b := T { 0, 1 }; (* <-- record constructor here *)
<*ASSERT a = b*>
END
will succeed
…On Sat, Sep 10, 2022 at 2:15 AM jpgpng ***@***.***> wrote:
@mikanystrom <https://github.com/mikanystrom> You said there is no
constructors. So what is this?
https://modula3.github.io/cm3/tutorial/m3/m3_52.html#SEC52
—
Reply to this email directly, view it on GitHub
<#1075 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKYNJP55OSN3OPCWO6DJF3V5RGSZANCNFSM6AAAAAAQJEWU54>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>