[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdi-dev] Build compatible extensions vs Portable extensions - naming
|
Hi,
On Friday, January 28, 2022, Matej Novotny <
manovotn@xxxxxxxxxx> wrote:
I am not much a player in these what-if games. We needed to introduce this new model and question of naming was open for probably over a year since we first started drafting them. No better name was agreed upon and that's how we landed on build compatible extensions. At least it captures the intent of usage (but doesn't limit it to just that).
I can understand that, and it’s fine.
But the key question remains:
What can the portable extensions do what build compatible extensions can not?
I don't see a good name here really. "Build compatible extensions" is a huge compromise and it sounds ugly, but I can't think of a better one. (I tried, there's a thread on cdi-dev, feel free to resurrect it.)
Buildtime extensions and Runtime extensions would have my vote, although it's indeed not entirely trivial if Builtime extensions are either secretly or explicitly runtime extensions too.
Yes, the trick here is that the new model is, in its function, not build time, it's build compatible. Since Lite is a subset of Full, any CDI Full impl has to support them as well (hence ensuring Lite -> Full portability) but CDI deliberately avoids stating whether those extensions need to be executed during build or run time because that's up to implementation. Existing CDI Full implementations can relatively easily implement build compatible extensions by executing them at runtime (which was one of the goals so as not to create a barrier for integrators). CDI Lite implementations will, typically, execute these new extensions during build time.
In short, a rename to BuildTimeExtension and RuntimeExtension would be wrong.
Which perhaps begs the question then; what sets the current Runtime Compatible extensions apart from the Build compatible extensions? What can the former do that the latter can't? If we can succinctly answer that, we may have our name.
When it comes to current portable extensions, I'd prefer not to rename, simply because the name has been in use for too long. That itself, in my eyes, trumps the other arguments.
That may be exactly the reason to consider a rename, if the only reason to not rename them is that they have been used for too long (yes, I know the reasoning here is somewhat circular ;)).
I am afraid I second Ladislav's opinion here. Renaming them would break compatibility of any existing application implementing them for no gain other than slightly different name.
Naming is important.
We now have two types of extensions; build compatible, and portable. It naturally says now that build compatible is not portable. Why else would the other type of extension be called portable?
To paraphrase my friend Greg from the Servlet spec; if you have a blue car and a red car, are they both red? Or does explicitly calling it a red car in this context means it’s the unique trait of that car compared to the other?
In that case, I'd rather have some javadoc explanation if people feel it is unclear and not break the whole thing.
A secondary question is, why would a name that’s only used in javadoc and the spec document break anything, let alone the whole thing?
Kind regards,
Arjan
Kind regards,
Arjan
Hi,
On Friday, January 28, 2022, Matej Novotny <manovotn@xxxxxxxxxx> wrote:
I wouldn't change what we needn't change.
But if need to change, we could change.
“Runtime only extensions” vs “Portable Extensions”.
Think about it in a different way, suppose those other extensions didn’t exist yet and we only had the build compatible ones. Now we had to vote on a name for those other ones.
What would be the chance you spontaneously would call them “Portable Extensions”?
The name build compatible extensions isn't perfect but the group came with no better. It basically captures the main intent for which they were proposed.
However, Lite is a subset of Full and as such Lite extensions can be executed in CDI Full as well in which case they will (most likely) be executed in runtime, just like portable extensions.
Basically, you can think of build compatible extensions as an extension model:
- working for CDI Lite
- portable between various CDI Lite implementations
- portable from CDI Lite to CDI Full
Matej
I think the reason why the name "build compatible extensions" stuck is that it is an extension of a runtime-only mechanism to build time. Portable extensions are not "runtime compatible", they are "runtime only". Build compatible extensions are runtime compatible too.
LT
Hi,
So if there's nothing vendor specific about the "build compatible extension API", and the word portable is completely superfluous (I agree), shall we rename portable extensions to "runtime compatible extension API"?
Kind regards,
Arjan Tijms
I think it's fair to say that the word "portable" is completely superfluous. If the extension mechanism is defined in the specification, it's portable by definition. The build compatible extension API is defined in the CDI specification (well mainly in the javadoc, just like portable extensions) and there shouldn't be anything vendor specific about it.
LT
Hi,
We now have two types of extensions in CDI; "Build compatible extensions" and "Portable extensions".
Do we mean to say that "Build compatible extensions" are not portable, and are vendor specific?
Kind regards,
Arjan Tijms
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
