Finalising the on-ramp feature

[Cay Horstmann]

Il 21/01/2025 21:48, Remi Forax ha scritto:
> I am a little disapointed by this proposal,
> As a teacher, it means that you have to explain the dot syntax early on, which is not necessary when discovering basic things like literals, control flow, arrays, user defined functions (yes, functions not methods, because the compact class is not visible, so everything is a function).
> 
> Yes, later on, when you explain the concept of IO, the dot syntax ('.'), the "println" inside "IO", the "parseInt" inside "Integer".
> But for the first lectures, there is no need to introduce the dot syntax.
> 
> More fundamentally, this proposal is weird to me, we want to introduce compact classes so there no need to declare a container class but to print something, you have to us a syntax that says go into the container class "IO" to find the method "println". So compact class => no container class, IO.println => container class ??
> 
> I understand that it means that the migration from a compact class to an ordinary class can be seen as more complex, but it's because you are skiping an intermediary step, which is moving from the world of functions to the world of methods. I think that the world of functions is important enough so we should support it, by allowing "println" to be an alias of "IO.println"
> 

It would be difficult to avoid Integer.parseInt, Math.pow, and so on in a Java-based introduction to programming. But why the fear of the dot? It marks these as coming from elsewhere. Good for the beginner to know. A clean and consistent model. No dot: defined in the compact class. With dot: defined in the API.

That's why I favor IO.println over unqualified println. It's consistent.

It would also be consistent if one could use unqualified parseInt, pow, println, etc., but nobody has come up with a satisfactory on-ramp, and not for lack of trying.

Cheers,

Cay

-- 

Cay S. Horstmann | https://horstmann.com