On 03/08/2025 11:11 PM, Brother Bill wrote:
> Am curious whether experienced D developers actually refer to both struct and class variables as "objects" without confusion.

Strictly speaking the definition from the C standard:

"region of data storage in the execution environment, the contents of which can represent values"

So it can describe a struct or class instance, but not a field.

I split the definition based upon what I am doing.

If its memory allocation, symbol representation type stuff, it'll be the C definition.
Otherwise I'll use the class description.

For most people they can stick with the class description, they don't need to know how C describes it, they are not working with the memory model at that level.

On Sunday, August 3, 2025 5:29:46 AM Mountain Daylight Time Mike Parker via Digitalmars-d-learn wrote:
> Classes and structs in C++ are both value types, and instances of both are referred to as objects. This isn't unusual.
>
> An object is a concrete instance of a type described by a class or struct definition. It's the thing you're manipulating, not the definition. Whether you're manipulating it directly or through a reference makes no difference. Whether it's on the stack or the heap makes no difference.
>
> Consider that a pointer to a struct a reference to the struct instance in the same way a class variable is a reference to a class instance.

Exactly. I don't think that I've ever seen anyone claiming before that a an instance of a struct should not be considered an object. An object is an instance of any class or struct, and inheritance has nothing to do with it.

And really, the whole concept that D has with structs vs classes is somewhat unique. C# has something similar (though IIRC, it's not quite the same), whereas in C++, the only difference between a struct and a class is what the default visibility level of its members are (public for structs and private for classes). And from what I've seen, most languages have just gone with classes. Glancing at Rust, it looks like they just went with structs, but I'm not very familiar with Rust, so I don't know the details. But either way, what exactly a class or struct is in a given language very much depends on that language. Some of the concepts are pretty universal, but the details can be quite different.

So, talking about structs vs classes in a general sense rather than when talking about a specific language isn't very useful IMHO.

Similarly, you'll get arguments over whether inheritance is a core part of object-oriented programming or not. Personally, I would have said that having a struct or class which has member functions - and therefore instances of that struct or class are objects with functions associated with them - would be the core of what it means for object-oriented programming and that inheritance was an extension of it and not a requirement, whereas some people would argue that inheritance is a core requirement of object-oriented programming. As I understand it, Smalltalk had a very different form of object-oriented programming than what folks normally think of today, and it was one of the first (if not the first) OO language, but many folks these days think of Java's form form of OO when they think of OO, which is probably why some folks think that OO must have inheritance in a manner similar to Java.

And the reality of the matter is that pretty much every language uses such terms in its own way which may or may not match what other languages use those terms for. So, if you want to talking about a concept such as an object or object-oriented programming, then you're going to tend to get a lot of comparing and contrasting between languages, sometimes with someone trying to claim that a particular language doesn't really qualify, because it doesn't fit how they use the term (which was probably strongly influenced by whichever languages they've used the most).

- Jonathan M Davis

On Sunday, August 3, 2025 9:31:34 AM Mountain Daylight Time Paul Backus via Digitalmars-d-learn wrote:
> I have never seen any D programmer use "object" to mean "struct or class instance."

That is always how I use the term. I see no reason to differentiate between what an instance of a struct is called and what the instance of class is called any more than they do in C++, where (as I'm sure you're well aware) struct and classes are basically the same thing, and there are plenty of classes which don't use inheritance at all, making them pretty much just like D structs.

And from what I've seen, folks routinely use the term object for instances of structs in D, and since D code typically uses structs more than classes, I expect that the term object is actually used to refer to structs in D far more than classes. I don't recall previously ever having seen anyone try to argue that instances of structs aren't objects, and the term object comes up enough in D discussions that I have a hard time believing that it's typically been intended to only mean instances of classes. But It's certainly possible that my preconceptions on the matter have colored my understanding of what people have said.

Honestly, I suspect that there are times where even instances of built-in types such as int or int[] get referred to as objects, since it's a convenient way to refer to an instance of a type (and it's not like everyone is always precise with their language). Personally, I wouldn't normally use the term object in such a fashion, but I wouldn't be surprised if I have some of the time simply because when talking about generic code, and you want to talk about the instance of the type being used, it's quite easy to just end up using the term object instead of talking about the instance of the type, particularly when it's frequently going to be a struct or class anyway.

> The standard term for grouping together
> structs and classes is ["aggregate,"][4] as in "aggregate type"
> or "aggregate instance."

The spec does use the term "aggregate type" to refer to classes, structs, interfaces, and unions, since they're all aggregates of values. However, from what I've seen, the term isn't used very often outside of the spec, and I don't think that I've ever seen the term "aggregate instance" before. From what I've seen, instances of both structs and classes are routinely referred to as objects.

Though thinking on it now, the situation is a bit weird with unions. The spec does say that user-defined types are aggregate types, and isAggregateType in std.traits is true for unions, but it can only have a single value at a time, meaning that it isn't an aggregate in the sense that it has multiple values. But it _is_ an aggregate in the sense that it can hold different types of values. Either way, it's a bit weird (though arguably, unions are just weird in general). However, as far as the isAggregateType trait goes, it probably does fit in with why you'd be using the trait, because you need to know whether it has members that you have to deal with, and unions do fall into that camp.

And thinking on it, I wouldn't really want to call unions objects, either because they can't have member variables or because I wouldn't ever consider passing an instance of a union around. I'd normally ever use a union for a member variable where it was encapsulated carefully, so I wouldn't be passing it around, and it wouldn't be part the API, so I wouldn't normally have any instances of it floating around to even be referred to as objects.

Regardless, it's not like we have a precise definition of what "object" means in D in the spec anywhere AFAIK. And the way that folks use it is probably strongly colored by their experience with other languages.

- Jonathan M Davis

On Monday, 4 August 2025 at 02:03:35 UTC, Jonathan M Davis wrote:
> I don't think that I've ever seen anyone claiming before that a an instance of a struct should not be considered an object.

Calling a plain old data like a vec2 an "object" is projecting and shouldnt be done.

---

The terminology of a worldview with lengthy prescriptions, shouldnt pretend to be merely descriptive. Bringing up a legal term with a precise punishment and criteria is understood to be a threat in several contexts.

OO clearly has natural claim to the word, and as a worldview is *wildly* prescriptive, whiny and moralizing. When any of all y`all use the term your invoking the conartist uncle bob and whatever connotations the listener has of that man and others like him, the empire of books, courses and supposed wisdom.

Maybe you dont notice others either signaling their political sides or letting it leak out unintentionally from word choice, but others are quite capable of it. An talk from an oo conference will probably use the term or more specif variants like "message"/"mailbox", while I bet the term is 5% of the "better software conference" with its data oriented sympathies would go with "struct"/"data"

On Monday, 4 August 2025 at 02:47:47 UTC, Jonathan M Davis wrote:
> The spec does use the term "aggregate type" to refer to classes, structs, interfaces, and unions, since they're all aggregates of values. However, from what I've seen, the term isn't used very often outside of the spec, and I don't think that I've ever seen the term "aggregate instance" before. From what I've seen, instances of both structs and classes are routinely referred to as objects.

The Structs page uses `object` quite a lot.

> Regardless, it's not like we have a precise definition of what "object" means in D in the spec anywhere AFAIK.

To complicate matters, the spec sometimes uses 'object' just to mean an instance of any type:

> If a pointer contains a null value, it is not pointing to a valid object.

https://dlang.org/spec/type.html#pointers

Note: git blame has my name on those lines, because I moved them there from arrays.dd. I think there are other places in the spec too but I've not found them after a quick look. Anyway that section could be fixed.