Should Delphi have native interfaces?

[Dalija Prasnikar 1396]

14 hours ago, Kas Ob. said:

One thing though, the point of having syntax in a language is to make written in a stone or let it evolve to something better, shorter, may be just more productive.

I am not against evolution, but that evolution must follow some basic rules - and not all rules are Delphi specific, some common language rules also apply. If you are building a castle, you cannot go ahead and add another tower by ruining the foundations first.

 

As far as rest of your posts is concerned, I am sorry to say, but I have hard time understanding what you want to say. Maybe it is the fact that you want to design things in different order is throwing me off course, maybe it is something else, but I cannot exactly pinpoint it.

 

[Guest]

I want to remove or enhance the way code is written and used to be shorter and more flexible, interfaces are merely a marker for the target (end line) and they will never be the target them selves, while current interfaces implementation is serve one purpose and you can have the same code without them, so what did they brought to the table ? ( not starting long discussion but merely trying to explain my point)

Reference counting, this should be against the one abstraction rule, they brought code limitation, so they (i mean in Delphi) already in grey area not like any other while not only abstraction, why stop there, why not make use of this syntax in code in something more helping like combine them with helpers, and this doesn't mean we are losing current interfaces usage.

 

Talking about castles, if the target is to have a castle with some specifics, these specifics or requirements will never list every things or how every detail should be, many is up to you to build and change as you see fit, after all building a castle might take months, now in case to be prepared of war i want to make a bridges in air between towers, this against all castle towers rules in the world but will serve the defenders greatly, can i do it ? or the interface and foundation will prevent me, and how is it hard to build/adjust if the foundation need a small adjustment.

Can foundations serve as tunnels ? or water storage ? or they only must be mute pile of stones and concrete ?

That well as object can be used in different project lets say building a farm, but here the object is the well ( aka water source) and the interface is just junk lines server nothing and almost always it will be a "castle-well", i prefer to bring the well as object and add when/if needed an interface for it per project not the way around, because the target is the farm here.

 

I am not sure how different i design things, but once a class had an interface almost 75% guarantee that class is belongs to one project realm and reusing it is limited in different project, interfaces in my opinion kills the portability and fatten the code uselessly, and most importantly when the building process is started which might be long time modifying the interface is slow process, i know i can put one class and object in one unit file, but this is ugly, i use interfaces only for the castle itself unless i see greater benefit for other internals but never for the halls, stables, walls, wells ... the stuff inside.

 

The discussion of interfaces and their usages is long and i don't see this is the case, simply put helpers are more efficient and more useful than interfaces (and faster), relaxing the interfaces where one can derive the interface itself from the "logic of the object" can be useful (of course in some cases) mixing helpers and interfaces might yield even more profits and save time (also in some cases), when i design the limit for my imagination is the sky and should not be the interface, for what it worth the greatest ideas comes while building not while designing, we as all developers might miss an idea when designing and struck gold while building, and having the design (blueprint) carved on metal or stone one might ditch it for the sake of saving time.

 

Another example, lets say i built the castle and delivered it, the owner asked why maintain cost is low, and it hit me i forgot to calculate the cleaning service company cost for all glass windows, how to fix that ? 

Went to my TRoom is is the base for all the rooms ( halls, bedrooms, stable..) and added the area of the glass window, this is imaginary example so that method is declared for interface in backward, so all other inherited interfaces ( and objects) from that base IRoomInterface will have it without touching a single interface, then added one method to the end-line interface of the castle as helper call, and that is it, no synchronized modification in two places.

 

My two suggestions might help be more productive by changing this 

Quote

           interface ----------> object ----------> helper

into something like this

Quote

          interface or

 in-place interface or  <----------> object ----------> classical helper

    on-demand helper

 

on-demand helpers might be very powerful and yet faster because they are not virtual calls, and doesn't need implementation or any change on object side.

in-place interfaces are build/extracted from the object and can be extended, so they are not on-demand but yet doesn't need an implementation as they are already implemented.

 

That was the pros, what are the cons with such suggestion ? and what the trade-off's (like quality of code) they might introduce that other implementation/approach does not (more or less) ?