2 Typo.
source | link

Obviously in most extant languages, members are treated fundamentally differently from methods, but does this HAVE to be the case?

Not for any theoretically-grounded reason. I think the reasons you don't see it often are practical:

The first is how you deal with these things at runtime. In Java or C++, an assignment to a primitive-typed public member like foo.x = 5 is easy to deal with: stuff 5 into some register, figure out where in memory the x member of foo lives and dump the register there. In a language like C# where classes can encapsulate intercepting assignments to members or pre-calculate how those members will evaluate, the compiler will have no a priori knowledge of whether the implementation of a class made available at runtime uses that feature. That means all public member assignments and evaluations toof public members have to be deferred to the implementation.* Operations involving a lot of access to those members end up taking a performance hit because they're constantly doing subroutine calls that could be handled faster with regular in-line assignments. Leaving evaluation and assignment separate from getters and setters gives the developer some control over how they're handled in a given situation.

The second is age. With the possible exception of F#, none of the languages in very wide use today is any younger than a decade, and even as recently as back then, the additional cycles required to make intercepted evaluation and assignment possible may not have been acceptable.

Third is inertia. I think to some degree, there's still some stigma associated with doing direct assignment to public members even if the language does allow the class to manipulate them and people still think in terms of getters and setters being better. That will wear off with time, just as it did with all of the people who had their noses in the air over people who wrote programs in higher-level languages instead of assembly.


*There's a tradeoff that comes with this: a language has to go whole hog with deferring evals/assignments to the class or balk at runtime if code using in-line evals/assignments for a given class tries to link with an implementation that intercepts them. Personally, I think the latter is a bad idea because it forces recompilation of code that uses an API that's unchanged.

Obviously in most extant languages, members are treated fundamentally differently from methods, but does this HAVE to be the case?

Not for any theoretically-grounded reason. I think the reasons you don't see it often are practical:

The first is how you deal with these things at runtime. In Java or C++, an assignment to a primitive-typed public member like foo.x = 5 is easy to deal with: stuff 5 into some register, figure out where in memory the x member of foo lives and dump the register there. In a language like C# where classes can encapsulate intercepting assignments to members or pre-calculate how those members will evaluate, the compiler will have no a priori knowledge of whether the implementation of a class made available at runtime uses that feature. That means all public member assignments and evaluations to public members have to be deferred to the implementation.* Operations involving a lot of access to those members end up taking a performance hit because they're constantly doing subroutine calls that could be handled faster with regular in-line assignments. Leaving evaluation and assignment separate from getters and setters gives the developer some control over how they're handled in a given situation.

The second is age. With the possible exception of F#, none of the languages in very wide use today is any younger than a decade, and even as recently as back then, the additional cycles required to make intercepted evaluation and assignment possible may not have been acceptable.

Third is inertia. I think to some degree, there's still some stigma associated with doing direct assignment to public members even if the language does allow the class to manipulate them and people still think in terms of getters and setters being better. That will wear off with time, just as it did with all of the people who had their noses in the air over people who wrote programs in higher-level languages instead of assembly.


*There's a tradeoff that comes with this: a language has to go whole hog with deferring evals/assignments to the class or balk at runtime if code using in-line evals/assignments for a given class tries to link with an implementation that intercepts them. Personally, I think the latter is a bad idea because it forces recompilation of code that uses an API that's unchanged.

Obviously in most extant languages, members are treated fundamentally differently from methods, but does this HAVE to be the case?

Not for any theoretically-grounded reason. I think the reasons you don't see it often are practical:

The first is how you deal with these things at runtime. In Java or C++, an assignment to a primitive-typed public member like foo.x = 5 is easy to deal with: stuff 5 into some register, figure out where in memory the x member of foo lives and dump the register there. In a language like C# where classes can encapsulate intercepting assignments to members or pre-calculate how those members will evaluate, the compiler will have no a priori knowledge of whether the implementation of a class made available at runtime uses that feature. That means all public member assignments and evaluations of public members have to be deferred to the implementation.* Operations involving a lot of access to those members end up taking a performance hit because they're constantly doing subroutine calls that could be handled faster with regular in-line assignments. Leaving evaluation and assignment separate from getters and setters gives the developer some control over how they're handled in a given situation.

The second is age. With the possible exception of F#, none of the languages in very wide use today is any younger than a decade, and even as recently as back then, the additional cycles required to make intercepted evaluation and assignment possible may not have been acceptable.

Third is inertia. I think to some degree, there's still some stigma associated with doing direct assignment to public members even if the language does allow the class to manipulate them and people still think in terms of getters and setters being better. That will wear off with time, just as it did with all of the people who had their noses in the air over people who wrote programs in higher-level languages instead of assembly.


*There's a tradeoff that comes with this: a language has to go whole hog with deferring evals/assignments to the class or balk at runtime if code using in-line evals/assignments for a given class tries to link with an implementation that intercepts them. Personally, I think the latter is a bad idea because it forces recompilation of code that uses an API that's unchanged.

1
source | link

Obviously in most extant languages, members are treated fundamentally differently from methods, but does this HAVE to be the case?

Not for any theoretically-grounded reason. I think the reasons you don't see it often are practical:

The first is how you deal with these things at runtime. In Java or C++, an assignment to a primitive-typed public member like foo.x = 5 is easy to deal with: stuff 5 into some register, figure out where in memory the x member of foo lives and dump the register there. In a language like C# where classes can encapsulate intercepting assignments to members or pre-calculate how those members will evaluate, the compiler will have no a priori knowledge of whether the implementation of a class made available at runtime uses that feature. That means all public member assignments and evaluations to public members have to be deferred to the implementation.* Operations involving a lot of access to those members end up taking a performance hit because they're constantly doing subroutine calls that could be handled faster with regular in-line assignments. Leaving evaluation and assignment separate from getters and setters gives the developer some control over how they're handled in a given situation.

The second is age. With the possible exception of F#, none of the languages in very wide use today is any younger than a decade, and even as recently as back then, the additional cycles required to make intercepted evaluation and assignment possible may not have been acceptable.

Third is inertia. I think to some degree, there's still some stigma associated with doing direct assignment to public members even if the language does allow the class to manipulate them and people still think in terms of getters and setters being better. That will wear off with time, just as it did with all of the people who had their noses in the air over people who wrote programs in higher-level languages instead of assembly.


*There's a tradeoff that comes with this: a language has to go whole hog with deferring evals/assignments to the class or balk at runtime if code using in-line evals/assignments for a given class tries to link with an implementation that intercepts them. Personally, I think the latter is a bad idea because it forces recompilation of code that uses an API that's unchanged.