When you define no protection modifier is default to public, while in Java it defaults to Fantom equivalent internal. Why did you choose for public and not internal, which seems more logic to me?
brianTue 2 Mar 2010
Just the simplest thing that will work for when you don't care (like scripts, etc).
As a general rule, I find the best place to limit exposing API is first at the class level (make as few classes as public as possible).
One thing to note is that Fantom actually checks that your public/protected signatures don't use internal types (Java doesn't do this).
tacticsTue 2 Mar 2010
The public by default makes sense for Fantom on multiple levels.
For one, it gives the language a very scripty feel when churning out code. Scripting languages rarely provide scope protection mechanisms. It's part of what gives them so much flexibility. Public and private become social conventions, and promoting a private member to a public one is as easy as changing your mind, without changing your code. So public by default is good policy for prototyping and drafting code.
The reason many OOP languages are so adverse to the public default is a technical limitation when you have a public field. If you change a public field to a method, every other class accessing that field breaks.
Fantom takes steps to minimize the damage done when this happens. Field reads and 0-parameter method calls look the same. Field reads in other classes are actually emitted as method calls behind the scenes. In other words, if a field is changed to a method in Fantom, it will usually Just Work.
jessevdamTue 2 Mar 2010
Thanks, I was just curious why this choice has been made. Fantom have to feel like a scripting language, so in that case this is the best choice.
jessevdam Tue 2 Mar 2010
When you define no protection modifier is default to public, while in Java it defaults to Fantom equivalent internal. Why did you choose for public and not internal, which seems more logic to me?
brian Tue 2 Mar 2010
Just the simplest thing that will work for when you don't care (like scripts, etc).
As a general rule, I find the best place to limit exposing API is first at the class level (make as few classes as public as possible).
One thing to note is that Fantom actually checks that your public/protected signatures don't use internal types (Java doesn't do this).
tactics Tue 2 Mar 2010
The
public
by default makes sense for Fantom on multiple levels.For one, it gives the language a very scripty feel when churning out code. Scripting languages rarely provide scope protection mechanisms. It's part of what gives them so much flexibility. Public and private become social conventions, and promoting a private member to a public one is as easy as changing your mind, without changing your code. So
public
by default is good policy for prototyping and drafting code.The reason many OOP languages are so adverse to the
public
default is a technical limitation when you have a public field. If you change a public field to a method, every other class accessing that field breaks.Fantom takes steps to minimize the damage done when this happens. Field reads and 0-parameter method calls look the same. Field reads in other classes are actually emitted as method calls behind the scenes. In other words, if a field is changed to a method in Fantom, it will usually Just Work.
jessevdam Tue 2 Mar 2010
Thanks, I was just curious why this choice has been made. Fantom have to feel like a scripting language, so in that case this is the best choice.