Class TreeViewNode property Tag are String

rgb

Think better if Tag are Object

bgrommes

rgb For just TreeViewNodes, or everywhere?

Historically I haven't made much use of Tag in other environments, as it feels like a crufty catch-all to me. But it can be a life saver, and my stance has softened of late. Object is more general purpose, at the expense of having to cast to the type you actually want ... but if it's Object then you can put any arbitrary class in there, and through the properties of that class, you can associate open ended info with the item the tag is attached to, should you need to.

rgb

bgrommes

Everywhere 🙂

All object in Objo are Object, make sense Tag are Object.

Personal opinion, i can be think wrong.

bgrommes

rgb In WinForms all Tag properties are Objects, but if you populate a Tag from the WinForms designer, you can only put a string into it. But programmatically you can put anything in there, and the documentation even suggests putting complex objects in there, for example, stashing customer order history in a DataTable or even a DataSet in the Tag property of a control associated with a particular customer. That seems like encouraging sloppy ad hoc design to me, and my use would be more, shall we say, restrained and considered. But it seems like just because a developer can shoot themselves in the foot doesn't mean you shouldn't give them flexibility. I think Tags should be Objects.

Bodevinaat

Everything is an object in Objo but maybe you mean Variant? That would make sense. You can store almost anything in a Variant.

bgrommes

Bodevinaat Everything in Objo inherits from the base class, Object. Objo does not have variants. It doesn't need them -- you just store any class instance in an Object (known as "boxing") and then cast to whatever you need when you pull it from storage ("unbox" it). Sometimes generics or interfaces are better choices; there's some overhead in (un)boxing if you're on a hot path. But for something like a catch-all Tag property, Object is a reasonable choice.

Garry

Thanks all. This is now implemented for the next release: https://feedback.objo.dev/feature/1061

TreeViewNode.Tag is now an Object, defaults to Nothing, and can store any Objo value. This makes it consistent with the other tag-bearing APIs.

node.Tag = New ProjectItem("/projects/main.objo")

If node.Tag IsA ProjectItem Then
    Var item As ProjectItem = ProjectItem(node.Tag)
    Print(item.Path)
End If

One small clarification: Objo does not need a Variant, and assigning a value to Object is not boxing in Objo’s language model. Every type already inherits from Object; you simply cast back to the concrete type when you need its specific members.

Thanks for spotting the inconsistency!

bgrommes

Garry Hi Garry, is there something different going on storing random things in object variables in Objo vs .NET? I have never thought placing values in .NET Object variables was actually different from any other downcast except in the limited sense that it's putting a value type inside a reference type. It is just that it represents casting overhead, but not some special-case / handling with extra overhead beyond any other up/downcast. But when it comes to value types, maybe it does?

Generics were introduced in .NET 2.0 in no small measure as the answer to this overhead, so that ArrayLists were deprecated over List<T>, etc. Wouldn't an Objo Array(Of Object) vs Array(Of AnythingElse) be somewhat analogous? In .NET one still would use either List<Object> or ArrayList on occasion when you need to store random things in a pile, but it's deeply ingrained in .NET devs to avoid it when possible (which is most of the time).

All this made me curious and I did a little searching and was surprised to find that Java and C# diverge here at a fundamental architectural level. Java has primitive wrapper types for all value types and behind the scenes, all Java generics do is implicitly (un)box primitive types in and out of objects. C# has no such deflection; it allows any type to be directly stored as type object, whether value or reference types. This seems on the surface, the same as Objo.

You're far beyond me when it comes to these matters; I have never written a compiler or a VM. So if you could help me understand any nuanced difference between Var foo As Object = 12 in Objo vs object foo = 12; in the .NET runtime, I would be grateful for the insight. Curious minds, and all that sort of thing :-)

Garry

Yes - there is an important difference, and I perhaps I should have distinguished Objo’s language model from its VM implementation more clearly.

In .NET, this is genuine boxing:

object foo = 12;

The CLR allocates a boxed System.Int32 on the managed heap and copies 12 into it. Casting back checks the boxed type and copies the value out. It is therefore more than an ordinary reference upcast.

Objo works differently. Every VM storage location (locals, properties and array elements) contains the same universal, tagged Value. An integer is stored inline in that value together with an Integer type tag; class instances are represented by references in the same kind of value.

Consequently:

Var foo As Object = 12

does not allocate an integer wrapper or otherwise change its representation. The compiler merely treats foo statically as Object; at runtime it remains an Integer-tagged value. Casting it back with Integer(foo) performs a type-tag check and returns the same value. There is a checking cost, but no .NET-style heap allocation or unboxing copy.

TreeViewNode.Tag likewise stores that universal Value directly. Assigning 12 to it stores the inline Integer value, not a newly allocated object wrapper.

This also means Array(Of Integer) versus Array(Of Object) is only partly analogous to List<int> versus List<object>. Both Objo arrays currently use the same Value representation internally. The generic element type provides compile-time safety and avoids explicit casts, but it does not produce specialised integer storage. In .NET, by contrast, List<int> avoids boxing whereas placing integers in List<object> boxes each one (one of the performance benefits of .NET generics).

So the short version is:

Objo: Var foo As Object = 12
       Upcast of an already tagged universal value; no wrapper allocation.

C#:   object foo = 12;
       Boxes an Int32 into a newly allocated heap object.

Your intuition about the distinction was therefore correct. My earlier “not boxing” comment referred specifically to Objo’s language and VM representation, not merely to different terminology for the same CLR operation.

bgrommes

Garry Thanks, Garry. This is very helpful to know! A cost, but a smaller one than .NET (un)boxing. And certainly less than Java. I would venture to say, not a meaningful cost for most practical use cases. Also for practical purposes, it can be regarded as simple casting. Excellent!