ceylon.math: Creating Whole and Decimals about ceylon-sdk HOT 8 CLOSED

The problem of visibility was discussed in length in ceylon/ceylon-spec#56 . There was a suggestion to make non-shared members visible to other code in the same compilation unit. In this case that would allow us to write toplevel functions (like createWhole(String)) that can access the non-shared members of the class as long as they are defined in the same file. Gavin actually wanted to consider this feature for M2 but looks like that didn't happen.

from ceylon-sdk.

I don't think the discussion in ceylon/ceylon-spec#56 fully addresses what I'm trying to do. I want to wrap a BigInteger or BigDecimal, in a Whole/Decimal but I don't want to declare it as a variable attribute because there's no need for it to be. This means I have to pass it to the initializer. But I can't hide the initializer without hiding the class itself. And making the type non-shared defeats the whole point!

I suppose I could use a shared abstract class with a nullary initializer and a non-shared implementation. But having two classes to achieve something as simple as this seems silly.

from ceylon-sdk.

@tombentley triage?

from ceylon-sdk.

Well, quoted literals are dead in the water at this point; I worked around the lack of literal support using the parse functions. The problem of initializers having the same visibility as the class is a known language issue. So at this point there's nothing to do about this issue. If we're happy with the currently solution, and the language isn't going to offer alternative solutions in the foreseeable future we could close it, I guess.

from ceylon-sdk.

FTR, my proposal to allow you to define a class that can't be extended outside of the module in which it is defined sorta kinda gives you a "private" constructor: just declare the class abstract, and then the only "constructors" for it are subclasses within the same module...

from ceylon-sdk.

But then it's another class.

We're coming back to the issue of multiple constructors, and the issues with implementing clone. I still think we don't have a good answer to those problems. As much as I will never miss overloading for methods, we haven't found a replacement for overloading constructors.

from ceylon-sdk.

Moving to M6.

from ceylon-sdk.

I think this is way out of date. We have parseXxxx() methods, and Whole/Decimal are interfaces. Closing, unless @tombentley objects.

from ceylon-sdk.