The project's headed to the wrong direction, unfortunately... about delphi-event-bus HOT 6 CLOSED

@edwinyzh I completely agree with @Nillissen .
It is true that using interface there is a little bit of additional work to create the interface but the benefits are so great:

• Memory Management: in this way DEB is not responsible anymore to free the objects that were passed to all subscribers
• The above involves in a faster execution because there is no need anymore to clone the object in order to pass different objects to subscribers. It was necessary before because they are async events and you cannot know when to free it
• Removing external dependencies: no clone no need of external units like RTTIUtils for object clone
• No memory leaks and DEB is not responsible to put you on the "wrong way"
• Cleaner repo. In addition to removing the external dependencies, the PR with the changes from an Object event to interface shows how much simple is now understand the code and architecture

I think given the above it is going on the right direction.
Happy to discuss and understand further your points :)

from delphi-event-bus.

@edwinyzh I must disagree with you 110%.

While the implementation of a message is only slightly more cumbersome, the benefits of an interfaced implementation makes up for this multiple times over.

I assume that you just don't understand the changes or the benefits of interfaces... because being lazy (needing to implement a little more code for each message) isn't a very good reason, especially seeing its your only reason.

This new implementation, particularly if you have multiple subscribers, greatly improves the speed and performance of the Delphi Event Bus. Also, it makes it much better if you are wanting use the Delphi Event Bus inside DLLs.

from delphi-event-bus.

@Nillissen and @spinettaro ,
Thanks for your comments. Now I'm reviewing my opinion. First, to clarify, it's not about being lazy, but to avoid duplicated codes.

Re. the benefits of events being interfaces, while I understand it simplifies the implementation of the DEB internals, but from the user's perspective, isn't that I can already use interface with the old version, just define:

TFileChangedEvent = class(TObject)
published 
  property SomeInterface: ISomeInterface read..; // will be set to nil in Destroy to avoid memory leaks.
end;

Re. the performance, with the old version I can already achieve great performance by defining published properties for the event object and cloning them using the good-old, high performance RTTI (system.TypInfo.pas)

Correct me if I'm wrong, and I appreciate your opinions.

from delphi-event-bus.

@edwinyzh in the case you mentioned it is still an object with all the consequences.
You are proving that we can achieve great performance with RTTI and published properties, that is ok, but given the fact we have removed the whole part that is not a problem anymore. We don't have to clone the object, facing again with RTTI and so on... Not sure if you got the point where we removed all of those and consequentially the code is easier and faster because is doing less, achieving more. how can we be faster than not doing it anymore? :D

from delphi-event-bus.

@spinettaro , I'm reviewing my opinion, and will try more (but the latest version didn't compile under XE4, need to find another time to fix it).

If I'm just starting out, I might be happy with the new interface-based design, however, with the existing code, I'd rather stay with the old version since I can already solve both the performance issue with old RTTI and passing of interface with the old Tobject-based events...

from delphi-event-bus.

closing

from delphi-event-bus.