Forum > Suggestions

Really VOID Class

<< < (5/6) > >>

Thaddy:

--- Quote from: damieiro on September 24, 2021, 12:48:32 pm --- Zero Cost.

--- End quote ---
Except bow and arrow notation to access the heap parts.... ->

MarkMLl:

--- Quote from: damieiro on September 25, 2021, 12:35:30 pm ---Pascal is a low level with strong types and better aproach to avoid mistakes and gives (INMHO) better foundation than C. Then, for low level, it could do the job same or better than C or C++ (less error prone).

--- End quote ---

As well as the moderately-strong typing, there are a couple of other distinguishing features.

The first is that Pascal allows up-level addressing (which changes the behaviour of the stack frame) and in its later incarnations supports explicit and implicit finalisation code (which changes the behaviour of the code blocks).

The second is that Pascal, as described by J&W, had implicit support for string operations including implicit I/O operations. And I'd emphasise that this was long before people knew how to define library interfaces which could accommodate that sort of thing: a minor change to I/O semantics required a compiler rebuild.

I would also say that the intention of Pascal was to be a viable successor to ALGOL-60, in direct competition to ALGOL-68. However unlike its immediate predecessor ALGOL-W it explicitly broke ALGOL syntax: Wirth was basically washing his hands of ALGOL because he felt slighted by the standardisation process (I blame John McCarthy for that).

I do not accept the characterisation of Pascal as a "toy" or "teaching" language, since it basically had the same functionality as ALGOL-60 as defined. And just as at least one ALGOL-60 dialect was used for systems programming (by Burroughs), at least one Pascal dialect was used for systems programming (by Cray).

And I particularly point a finger there at people who criticise Pascal's lack of explicit named-file handling and text output formatting since neither of those was defined by core ALGOL-60, which didn't stop various derivatives borrowing e.g. FORTRAN's standardised formatting strings.


--- Quote ---I think we are mixing syntax with power. A void class gives a power tool to the developer. Perhaps useful, perhaps useless, but gives the basic foundation. Tobject it's too big. And object it's not properly maintained (well the effords won't be here).

--- End quote ---

I presume that what you're really talking about here is TVoid as an ultimate ancestor? (Don't peer into it, it's empty.) "Void class" is a bit close in naming to "nullable instances" etc.

I think I'd point out that Advanced Records might be worth considering as a lightweight alternative to both objects and classes... in fact I believe that at one time Wirth was wont to rant about how nothing done by OO programming couldn't be similarly achieved by records in Oberon.

And I'd suggest that if you really need an ultimate TVoid then the nature of an open-source project like FPC means that you can write and submit an implementation as a patch, but I am troubled by the comments in the current TObject(?) implementation that some of the VMT offsets are "graven in stone" due to the requirements of supporting assembler code. And if you weren't satisfied by the reaction to your patch, you could obviously fork the project.


--- Quote ---I think, for example (this could be as a general view) that if i would like to do a smart pointer (a low-middle level aproach) in C++ i can do it with oop paradigm or structured. In FPC i cannot do it because of the overbloat with classes. But i can, ironically, make my own memory manager, to, for example, redirect all heap calls to stack calls or my own internal memory.

--- End quote ---

I think you can do it by overloading the assignment operator, specifically defining Tsomething := PTsomething. However this is likely to get extremely messy since as I understand it the := operator is used for both explicit assignment and implicit casting... I'd be happier to see those distinguished and also to see ^ and possibly @ as being overloadable.

MarkMLl

marcov:

--- Quote from: damieiro on September 24, 2021, 02:12:51 pm ---Do the calculus:
how many bytes is the minimal size of a TObject?

--- End quote ---


--- Code: ---{$mode delphi}

uses classes;
var x : tobject;
begin
 x:=tobject.create;
writeln(x.instancesize);
end.

--- End code ---

Prints "4" on a 32-bit system, which is due the VMT pointer that is needed to make the difference between objects and records. Anything without it is not an object but a record/struct.

Note that in Delphi the instance size is afaik double that due to the monitor field. (which I still don't understand why they made it global rather than part of some sync primitives ancestor, but I don't comprehend their use entirely)


--- Quote ---How many indirections even for a simple task like constructing it?. Then ask same for a void one (a similar c++ example).

--- End quote ---

No idea. Many probably. But we are talking about classes/OOP here, and not bare structs. So there needs to be some functionality in there somewhere.


--- Quote ---But the main gain is not that.
The main gain is to eliminate dual mainteinance of object/tobject and the aperture of a powerful tool with full compatibility (really even more potent that the c++ counterpart, more mainteinable and similar or better speed).

--- End quote ---

Eliminating Dual maintenance, full compatibility and extensions are three things that are probably mutually exclusive.


--- Quote ---Please. Figure how to implement it and as compiler dev you will see a lot of sinergies. Like the academical view find.

--- End quote ---

We don't see the synergies, and to be frank, you are not doing a really good job advocating them either. A lot of sentiment and spin, but low on facts and design.

I've read three pages of replies, and I have seen nothing but throwing random C++ functionality about and some deep seated belief that there should be something below tobject.

korba812:

--- Quote from: damieiro on September 24, 2021, 02:12:51 pm ---how many bytes is the minimal size of a TObject?
--- End quote ---
The size of the empty class data (like TObject) is exactly the same as the data size of an empty classic object - it's just the size of a pointer to the VMT.  How classes and objects would work without a VMT?

Blade:

--- Quote from: Awkward on September 23, 2021, 08:52:18 pm ---dual model is bad idea? say that to advanced record creators! THAT was a bad idea, to make records with bonuses if we has objects already. And your Void classes will be little more than unuseful coz direct descendants will be not compatible with TObject descendants

--- End quote ---

Advanced Records is a great idea.  Various programmers don't want the syntax baggage associated with Class-based OOP or various aspects of OOP such as inheritance (where it can be unclear what has been inherited).  Note- keep in mind that records/advanced records can do direct inheritance, that is a record contained within another record.

Object Pascal's situation is a very good one, because by having records, advanced records, objects, and classes then the programmer has greater freedom to choose what they believe will be best for them.  It helps removes OOP style spaghetti or unnecessary complexity where possible.

Usually the only situations where a programmer will be forced or obligated to use something they don't like is because they have a boss who has mandated it must be done a certain way, their company is paying them to do so, and they don't want to quit.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version