• Amex (45/45) Jun 02 2019 Debugging in Visual D allows one to easily explore the hierarchy
• Adam D. Ruppe (5/8) Jun 02 2019 Have you tried just writing a function outside the object that
• Amex (10/18) Jun 03 2019 Maybe... but I'm mainly looking to be able to add information to
• Dominikus Dittes Scherkl (6/8) Jun 03 2019 That's a really good question.

Amex <Amex gmail.com> writes:

Debugging in Visual D allows one to easily explore the hierarchy 
of classes.

One problem is being able to easily find other related objects 
within the hierarchy that might be an ancestor.

It would be very useful to be able to "inject" reference in to 
Object so that one could add such information that would be 
available to all objects.

This is more useful in general. Maybe one wants to add common 
functionality too all objects in the program that Object does not 
support yet the program was not designed with a base Object. 
Furthermore, since D is single inheritance it makes it somewhat 
impossible to use this for the debugging method above since 
visual D can only show fields.

Idea:

Allow one to extend object. D does not have partial classes, 

extend it by some means other than extending recompiling DMD, 
LDC, GDC.

class Object:Extend
{
     int RC = 0;
     void Display() { ... }
}

And then RC and Display will be available to all objects.

Display could be a visual inspector for the app's object's and RC 
could be a resource counter.

I don't care about the specific syntax, just the ability to 
easily have the functionality(again, without having to fork my 
own compiler or standard lib).

I don't see why we can't do this, there really are no excuses. I 
should have full control of my own app and what it can do or not.

I realize that it could cause problems for objects compiled in as 
a library that would not have such an extension. These are easily 
dealt with by simply using the new object as the base.

e.g., what we really have is

class Object : Object;

But the base is the original object and the new Object is what is 
used throughout the app(rather than the base). i.e., we really 
have

class ObjectNew : Object;

and as if all our classes in code derive from this ObjectNew 
rather than Object.

There might be a few minor complications but nothing that can't 
be overcome... Even if it's limited to debugging it would be 
worth it.

Adam D. Ruppe <destructionator gmail.com> writes:

On Sunday, 2 June 2019 at 15:27:07 UTC, Amex wrote:
 It would be very useful to be able to "inject" reference in to 
 Object so that one could add such information that would be 
 available to all objects.

Have you tried just writing a function outside the object that 
takes it as a parameter? It seems like that could do what you 
want today.

void Display(Object _this) { ... }

Amex <Amex gmail.com> writes:

On Sunday, 2 June 2019 at 20:16:15 UTC, Adam D. Ruppe wrote:
 On Sunday, 2 June 2019 at 15:27:07 UTC, Amex wrote:
 It would be very useful to be able to "inject" reference in to 
 Object so that one could add such information that would be 
 available to all objects.

 Have you tried just writing a function outside the object that 
 takes it as a parameter? It seems like that could do what you 
 want today.

 void Display(Object _this) { ... }

Maybe... but I'm mainly looking to be able to add information to 
all objects(fields) and mainly this is for debugging purposes 
because Visual D/Studio does not allow one to always get at 
certain global variables(One has to specify the fully qualified 
name and jump through a few hoops)...

But I figure it could be useful for other things too. I just 
don't see why we can't do have such a feature. I mean, if 
everything could be done with extension methods then why have 
object in the first place?

Dominikus Dittes Scherkl <dominikus.scherkl continental-corporation.com> writes:

On Monday, 3 June 2019 at 08:09:17 UTC, Amex wrote:
 I mean, if everything could be done with extension methods then 
 why have object in the first place?

That's a really good question.
And my personal answer is: objects are kind of outdated stuff. 
Some Object kernel may still be of didactic or documentary use, 
but no need to add special or complicated stuff to them. That is 
most of the time better done with extension methods.