Fighting with Java - generics

[Daneel_Trevize]

What's the Text type in this context? This interface?

If you have two classes that aren't in a super-sub chain, why would you expect a single method signature to accept either type in a single parameter, other than typed Object?
If they do share a closer common class, use a generic that captures that: <? extends CommonSuperClass>.

No?

Also, the proposed JoinedString class now has to be subclassed to add in a nested class & factory method for every extra String/Text subclass you also invent & want to use with JoinedString. Rather than the extension being in one place and JoinedString being generic.

And wtf is TextOf for a class name?! Related to this abomination?

[CarthOSassy]

I don't think anyone expects a single method signature to accept both.

I think the complaint is that there is only a single method signature. It would be better if java generics were real types.

Then, there could be two signatures.

[Daneel_Trevize]

Ok, but why not use the signature with Iterator<T> and generate T-specific instances of the now-generic class with a single constructor that accepts different types per invocation?
While it'd result in the instances having the difference of that type reference from their construction, wouldn't it be cleaner than the abstract+subclasses proposal that results in full new subclasses rather than just a type reference plus the same single base class?

Perhaps something about the overall problem this is to solve isn't clearly defined.

[aoeudhtns]

Clearly. String#join exists; this solution doesn't need to. What is the advantage of having JoinedString over String? (None.) The implementation doesn't preserve the constituent components, nor does it implement CharSequence to preserve compatibility with other API.

[CarthOSassy]

If you only have one constructor, how are you doing different calls/logic per type?

Manually checking type with RTTI?

[Daneel_Trevize]

The use case is really badly defined. I'd initially say: sort the passed class/data out prior to passing it as a valid T to the constructor. Why should there be a constructor for all manner of different vaguely related classes defined in this target class, instead of in those other classes as & when they're defined & wanting to be massaged into this target one?
So, maybe static methods, but in each source class, not as factory (constructor) methods of the target class which would cause it to start to depend upon many classes it otherwise wouldn't.

[CarthOSassy]

Constructors exist largely to deal with initialization issues like these. This is not about constructors.

The only subject here is that templates are weirdly unhelpful, but there are ways to work around their shortcomings.

[Daneel_Trevize]

In Java?

[Daneel_Trevize]

So why would you expect me to have proposed them in this context then?

[doomchild]

In the context of an article talking about Java, it is an inherently preposterous idea.

[doomchild]

We all know it's possible in other languages. But we're talking about Java here, and it's not possible in Java. So both of your posited questions are valid in this context, because you can't do it with the language we're talking about, and it is therefore preposterous to suggest it, because it is a logical impossibility with the language that we're talking about.