On Monday, April 9, 2012 5:50:32 AM UTC-4, Niels Braczek wrote:
Am 07.04.2012 14:27, schrieb Andrew Eddie: > On 7 April 2012 19:04, Niels Braczek <nbra...@bsds.de> wrote:
>> If >> that means to go another way than just the pure academic one, it is ok >> for me. > > I think we've established it's more than just academic.
Please understand me right: I'm just talking about the *naming* of the interfaces. Everything else is just fine for me.
>> The goal for both platform and CMS should be to get rid of the legacy >> library. > > Well, yes and no. [...] Why all the complaints about it all of a sudden?
I surely understand the need of the legacy tree, and what it is good for, as I stated in my next sentence.
>> It is needed to get around unavoidable BC issues, but it is not >> an invitation to break things, where it can be avoided.
> I think we are all good enough developers to acknowledge that and > respect that we would judge such situations professionally.
I absolutely agree.
> There > seems to be the perception evolving that Louis, Rob, Sam and I don't > know what we are doing and couldn't care two hoots about the impact on > downstream users just because we work at the same place. That's a > pretty bitter pill to swallow given our combined years of service.
I'm sorry, if that is what you read between my lines. That's not what I tried to communicate.
>> One single issue >> with that legacy library is that it prevents code completion from >> working properly, because duplicate class names add ambiguosity, which >> can't be resolved by an IDE (that problem exists in some other places, >> too, but that should rather be fixed than be used as an excusion). > > That's actually a fair comment - not enough to move me, but fair.
I'm sure you'll agree, that duplicate class names should be reduced to a minimum. It is a requirement of clean code.
>> So, just name the interfaces JModelInterface, JViewInterface and >> JControllerInterface, and there abstract counterparts JModelBase, >> JViewBase and JControllerBase. Each application (like the CMS) is then >> able to provide their own base classes called JModel, JView and >> JController. The CMS will just have to refactor their own three base >> classes, and every existing extension will work *unchanged*. That's what >> I'd call responsible improvement. > > And Rouven proposed a very simple forward compatibility strategy to do that.
Could you point me to that proposal? I must have missed it. The only thing I found was https://github.com/LouisLandry/plugin-compat, but that does not solve the problem: If JModelBase implements JModel (an interface), how can the CMS provide another JModel class which extends from JModelBase?
> I may ultimately loose this battle, but I really dislike the > *Interface naming because it's not the lead PHP takes itself, nor > leading pattern architects like Martin Fowler and others I'm sure. We > don't do it for abstract classes and everyone seems to survive quite > nicely. The issue is, what we do for interfaces here, we set as the > standard.
Well, I'm a fan of Martin Fowler, and he's always been a great inspiration to me. But in this case, we are not free in our decisions, since we've got dependencies. In this case, it is just a question of naming. The 'Interface' suffix is not beautiful, but would allow a smooth transition to the new MVC by refactoring just 3 classes in the CMS. Without the suffix, several thousand classes and scripts have to be changed.
> At any rate, even if the interface names didn't collide, we still need > the legacy tree to buffer the changes in the CMS till at least 4.0 (2 > years away).
Accepted, since it is useful, even if it is not beauty. I guess we'll always have some kind of a transitional tree, just to decouple development cycles of CMS and platform. That makes sense.
> So I'm taking it that even if you think the code is > good, the whole pull is a -1?
Absolutely not. I like the proposal. I'm just unhappy with the consequences of the suggested naming.
> To me that's disappointing because it > is a good refactor (in my opinion). The platform simply doesn't need > the current, very heavy and CMS centric MVC classes.
FullACK. The CMS should be able to adopt to the new MVC without pain, and - what IMO is most important - without again forcing extension developers to rewrite their code just because of naming issues.