Given 3 cfcs, abstractBase.cfc, abstractSpecific.c...
# cfml-general
j
Given 3 cfcs, abstractBase.cfc, abstractSpecific.cfc, and childSpecific.cfc. childSpecific extends abstractSpecific, which extends abstractBase. When instantiated, child's init() calls super.init() of abstractSpecific, which calls super.init() of abstractBase. However, this is only seeming to work if abstractSpecific is not an abstract component. Am I wrong in believing that an abstract component's init() should be able to call the super.init() of it's parent abstract component? There is a cf blog post from 2018 that shows that I can... https://coldfusion.adobe.com/2018/07/oop-and-coldfusion/#:~:text=Abstract%20Component%20%26%20Methods%20have%20been,both%20abstract%20and%20concrete%20methods.
a
Instead of describing the code, actually giving us a gist with an example of what yer doing would have been really helpful here. Because as it stands, now if we wanna investigate, we have to mess around duplicating the work that you've already done.
j
AbstractBase.cfc
/**
* @output false **/ abstract component{ /** * @output false **/ public AbstractBase function init(){ return this; } } AbstractSpecific.cfc /** * @output false * @extends AbstractBase **/ abstract component{ /** * @output false **/ public AbstractSpecific function init(){ Super.init(); return this; } } ChildSpecific.cfc /** * @output false * @extends AbstractSpecific **/ component{ /** * @output false **/ public ChildSpecific function init(){ Super.init(); return this; } }
Variables.c = new ChildSpecific();
a
that wasn't a gist, was it. It was just a whole sea of code inline, not even with formatting 😐 This is a gist: https://gist.github.com/adamcameron/e4bd8592a047def27a4455627704d248 (and it works exactly how I'd expect, guessing what you were meaning) But anyway... lemme look @ this code of yours
You don't need all that
@output
stuff in script-based CFCs btw. Script code doesn't bleed whitespace, which is all that annotation addresses.
It's cos yer using annotations I think
Instead of just... using code.
If I update yer code to use
component extends=AbstractSpecific
etc, it works fine.
j
well, that's interesting, first time in over a decade i've had a problem with annotations
a
Just gonna try your code on Lucee and see what it does
To me - and only looking into it superficially - your code ought to work. However I've never used annotations for another other than hints, so not something I'm that familiar with
j
i've used them for everything, accessors on properties, component settings, as much as I can
a
No comment. 😉
😁 1
Lucee barfs too
Copy code
Message	component [ChildSpecific] has no private function with name [init]
Detail	accessible functions are [INIT]
Weird error though
j
very.
a
Yeah and Lucee works fine if you use code rather than comments
j
only seems to be a problem for me with abstracts
a
oh
Ah yeah. CF is fine if I take the
abstract
modifier off the component. Lucee still faceplants. So you've found a bug in each. Nice work.
OK so clearly the intent is that
@extends
should work. They just screwed it when they added
abstract
If you use
@abstract true
in an annotation, it works
(can't believe I am encouraging ppl to use more comments 😐 )
😆 1
😉
(on CF I mean. Not on Lucee)
j
I'm on a roll finding obscure bugs this year
😛 1
a
I'll add another vote that comments should not alter how code runs. Comments are, erm, comments (the annotation is inside a comments block). They can be useful for generating documentation. I'm sure it looked cool at the time Adobe decided to add it, but means that we have 3 ways for everything (cftag attributes, cfscript attributes and cfscript comment annotations). Having said that, as it is a thing, it should work :)
2
a
Yep it's def an approach to writing code I would actively dissuade in an environment when I make the calls on such things. I think doing stuff in comments when it can be done with code is... weird. Ah well.