Anyone use private fields with public get set ?

Monkey Archive Forums/Monkey Discussion/Anyone use private fields with public get set ?

Rushino(Posted 2013) [#1]
Just wondering to know if i am the only one that use private fields with public get set... sometime i feel like this is leading to bigger files and maintenance cost. But since i am purist i tend to do them anyway.. it make the class more encapsulated. What your opinion ?

Thanks!


Gerry Quinn(Posted 2013) [#2]
I don't use them. If I want a field to be other than a 'real' field I explicitly create a Get() or Set() function. Probably just habit from C++.


ziggy(Posted 2013) [#3]
That's what properties are for.
Class MyClass
   Method MyImportantValue:Int() Property  'This is a getter
      return myImportantValue
   End
   Method MyImportantValue:Void(value:Int) Property  'This is a setter
      myImportantValue = value
   End
   Private
   Field myImportantValue:Int = 0
End

So you can use it like this:
Local myInstance := New MyClass
myInstance.MyImportantValue = 34 'Setter property is called here, the one that accepts one parameter.
Print myInstance.MyImportantValue 'Getter property is called here, the one without parameters that returns an integer.


It gives you the validate changes and "react" to them
Class MyClass
   Method MyImportantValue:Int() Property
      return myImportantValue
   End
   Method MyImportantValue:Void(value:Int) Property
     'Validate if value is valid:
     if IsValid(value) = false then Error "Illegal value for MyImportantValue!"
      myImportantValue = value
      'React to changes:
      Self.RecalculateImportantThings()
   End
   Private
   Field myImportantValue:Int = 0
End



Beaker(Posted 2013) [#4]
I'm using Properties more and more. They are a great way to block setting altogether, or for adding small amounts of extra functionality to setters.


Gerry Quinn(Posted 2013) [#5]
To me it is just disguising a function as a field. I see it as the creation of obscurity for no real advantage. Unless your design is broken in the first place and you have been accessing public fields but now realise it was an error and you need to quietly replace the field accesses with functions.

I can see some merit in it for things like GUI libraries, I guess.


ziggy(Posted 2013) [#6]
I see it as the creation of obscurity for no real advantage. Unless your design is broken in the first place

It's only "obscurity" if you assume all atributes are fields. But that's a bad idea on languages with properties. Having a strong naming convention is a godsend!

In my honest opinion, that has much more to do with encapsulation. if you ask me, public fields should not be allowed in the first place, and a good compiler should inline field access when the property does not have any executable code attached to it. That would be, from my honest point of view, the perfect handling of object attributes.
I'm not sure if that's your case, but I usually find coders that come from the c++ world disliking properties, while coders coming from object oriented programming languages, do use them much more frequently.

Anyway, the joy of Monkey is that you can use it if you want, and you can avoid them.


wiebow(Posted 2013) [#7]
I avoid Properties. I can set Vector.x just as easily, no one else is using my code, and I am not coding some kind of complex API, so who am I protecting from what?


Gerry Quinn(Posted 2013) [#8]
If I have only fields and functions, I don't *need* a naming convention to distinguish them! And if I want to allow access to a public field, I can do that, and know when I'm doing it.

Properties are syntactic sugar, like operator overloading. If I had to choose one, I'd choose the latter. Though it may be that neither form of sugar, however sweet, is really all that good for you.

(By the way, C++ is an object-orientated language.)


ziggy(Posted 2013) [#9]
By the way, C++ is an object-orientated language.
I honstly don't think so. Anyway, this is a never ending debate. You would agree, at last partially, that this is very arguable.

As far as I know, this is a c++ program:
#include <iostream>

using namespace std;

int main()
{
	cout << "Hello World!" << endl;
	return 0;
}
   
We are objects!!?? Some people say this is becouse C++ is a multi-paradigm programming language. I can't care less how it should be classified but the above example has nothing to do with OO coding.

There's a lot of debate:

http://stackoverflow.com/questions/1635583/is-c-completely-object-oriented-languge

http://programmers.stackexchange.com/questions/48320/is-c-not-suitable-for-oop

Most interesting:
http://en.allexperts.com/q/C-1040/C-pure-OOP-Language.htm

http://programmers.stackexchange.com/questions/46592/so-what-did-alan-kay-really-mean-by-the-term-object-oriented

If you want to considere it OO for whatever reason, go for it! But claiming it is OO, like it was something that everybody knows and accepts, is just false. Smalltalk or Simula are OO languages, and Java or C# are much more OO than C++ is. As far as I know, this is much more commonly accepted, and for good reasons.

Several important authors such as Matt Weisfeld, do not considere C++ an true OO programming language: "We have already mentioned that C++ is not a true object-oriented programming language but is actually an object-based programming language. Remember that C++ is considered to be object-based. Object-oriented concepts are not enforced. You can write a non-object-oriented C program using a C++ compiler."
—Matt Weisfeld
(You can read more on this subject in this very interesting book: http://www.amazon.com/Object-Oriented-Thought-Process-Matt-Weisfeld/dp/0672330164

Properties are syntactic sugar, like operator overloading.
Yes! The same as classes, generics, methods, but they can be useful!

EDIT: Not even the wikipedia classifies it as an OO language, which is kind of fun: https://en.wikipedia.org/wiki/C%2B%2B#Criticism


Gerry Quinn(Posted 2013) [#10]
Presumably you would not class Monkey as OO either:

Function Main:Int()
	Print "Hello World"
End


What C++ does offer is a full toolbox of programming techniques, plus C compatibility. Just because it allows non-OO techniques doesn't mean it's OO capabilities are weak, non-existent, or irrelevant..

Wikipedia notes that C++ was designed from the start as an attempt to enhance C by adding features from Simula, widely considered the first OO language.

What does happen a lot is that various purists and obsessives either diss it (because it's not crippled like their preferred language) or try to claim it as an example of their pet programming theory (because it has the power to handle lots of paradigms including the one they are trying to boost).

As for Matt Weisfeld, I haven't read his book, but the publisher's description begins with: "Object-oriented programming (OOP) is the foundation of modern programming languages, including C++...". Even he clearly accepts that his cavilling about whether C++ is object-oriented or some new object-related term he just invented doesn't mean very much.

C++ is object-oriented because idiomatic C++ uses objects for most purposes. Its main benefits are compatibility, expressive power, and efficient code. Its main defects are clunky syntax and over-complexity, not a lack of object orientation.


ziggy(Posted 2013) [#11]
Presumably you would not class Monkey as OO either
I don`t.

What does happen a lot is that various purists and obsessives either diss it (because it's not crippled like their preferred language) or try to claim it as an example of their pet programming theory (because it has the power to handle lots of paradigms including the one they are trying to boost).
That's true, but the fact that you classify them as "purist and obsessives" doesn't make them automatically wrong.

Object-oriented programming (OOP) is the foundation of modern programming languages, including C++
Nobody denies that OO is one of the foundations of C++. That does not implie that C++ is OO.

If you read this Alan Kay sentence, it explains a lot:
"It is interesting to see what is being done out in the world under the name object-oriented. I have been shown some very, very strange looking pieces of code over the years, by various people, including people in universities, that they have said is OOP code written in an OOP language—and actually I made up the term object-oriented, and I can tell you, I didn't have C++ in mind."
If anyone reading this do not know who's Alan Kay, he was the creator of OO programming concept and co-creator of Smalltalk.

And finally, just to be clear, the fact that C++ is not OO, or not pure OO, doesn't make it bad or anything. I think the C++ lovers love it, becouse it's flexibility and the fact that it allows you to ebrace several paradigms at the same time. That's where its power resides. but this is just possible becouse it is not a true OO language.
It fails to proper encapsulation, it has multiple inheritance, and several other things that are properly explained in the aforementioned links.

Eitherway, is it *that* important to clasify it?

C++ is object-oriented because idiomatic C++ uses objects for most purposes
Care to explain how could I extend an int?


Paul - Taiphoz(Posted 2013) [#12]
not sure where I stand on this, I as of yet have not used a property, not seen any situation where using one over a field gave me some benefit.

is there any real world examples of where a field simply cant cut it and a property needs to be used?


Gerry Quinn(Posted 2013) [#13]
I should have added to my earlier post: I do not consider classes, generics, or methods to be syntactic sugar, because they all add greatly to the expressive power of a language. Properties and operator overloading don't; a language that has them would be much the same language without them.

People were doing OO programming in Simula etc. long before Alan Kay coined the phrase.

As for extending an int, C++ actually comes way closer to the ability to do that than a lot of languages. Take Java, for example (please, take it!). In Java - like Monkey - there is a clear blue line between primitives and objects. Probably the underlying issue is that Java objects have too much overhead to use freely if you are shooting at efficiency.

In C++, by contrast, although ints are a built-in type for compatibility with C and I guess for compatibility with rapidly evolving hardware architecture, you could define objects that are essentially ints, and use and extend them freely with no loss of efficiency.

Maybe one should argue that C++ is much *more* of an OO language than languages like Java and Monkey because it doesn't really depend on a concept of primitives that are different from objects. You could call languages like Java primitive-oriented languages.

Most of the arguments that C++ are not object-oriented are based on what it can do rather than what it can't do. That puts them on pretty shaky ground right away IMO. X is not a real rugby-player; he can play golf!


ziggy(Posted 2013) [#14]
I do not consider classes, generics, or methods to be syntactic sugar, because they all add greatly to the expressive power of a language. Properties and operator overloading don't; a language that has them would be much the same language without them.
I agree to most of it. But I considere Properties a very good (not necessary) encapsulation method. That's why I like them.

People were doing OO programming in Simula etc. long before Alan Kay coined the phrase.
Of course. Not sure what that means but I'm sure they were not doing it in C++ or Java or C#.

In C++, by contrast, although ints are a built-in type for compatibility with C and I guess for compatibility with rapidly evolving hardware architecture, you could define objects that are essentially ints, and use and extend them freely with no loss of efficiency.
Yes of course! C++ is VERY powerful. But other (much more oo) languages such as C# resolve this with a more academic approach where Int are really structs that happen to implement several methods, etc.

Maybe one should argue that C++ is much *more* of an OO language than languages like Java and Monkey because it doesn't really depend on a concept of primitives that are different from objects.
As long as Java does enforce the usage of classes everywhere, I would consider much more OO than C++. Also it has better encapsulation and much more code safeness than C++ (encapsulation and a proper message system between object is one of the key points of the OO paradigm that can be so easily violated on C++, and not so easily in Java). Java is not perfect in lots of areas but I have to choose C++ or Java languages I would choose Java as long as I do not need to use the uggliest compilation system I've seen that is the one provided by the official Sun Java compiler(s) and toolchain. What have we done to them? Why do they hate developers?

Most of the arguments that C++ are not object-oriented are based on what it can do rather than what it can't do. That puts them on pretty shaky ground right away IMO. X is not a real rugby-player; he can play golf!
Agree, but when you're not working alone, and you pass the rugby ball to another player just to find out he's playing golf, and then another member of the team has just modified both the golf and rugby rules, while someone else in the team is just playing Poker... I would not call it a rugby match. That's the main reason why C++ is not a OO language. You can find teams of people mixing paradigms and this can lead to not very pleasant experience and it can increase dramatically maintenance costs. That's why there are other much more widely used languages for several business or desktop development.

Honestly, I can't care less if this is or not important. As long as it helps get the work done... Who cares?. But as a sort of "academic" debate, I honestly find it kind of interesting.


Nobuyuki(Posted 2013) [#15]
Back to topic,

Yes, I do use Properties in a few of my classes, in order to enforce Interface requirements. Some interfaces would not operate properly without at least a few fields which are expected to be there, and it's a shame that we can't simply define Fields in an Interface, but there is probably a good logical or syntactical reason why we can't. I'd probably have a lot more use for Properties if we had a Protected directive -- it is often a lot less confusing to the end-coder when dealing with 3rd party classes to only have properties exposed to them, which is important in cases where the Getter or Setter change some other state variables.

VB.NET uses Properties extensively, so I'm used to the idea of encapsulation. However, newer versions of VS have auto-implemented Properties, which currently none of the Monkey IDE's have. This would be really nice to have, especially when writing an interface that has a number of required fields.

Right now, for large "interface-satisfying" property blocks, I encapsulate them inside a '#Region block inside the implementing class. Each property I write has to have the getter and setter defined in a way that is more verbose than VB, so having some sort of macro to auto-write these would be even more helpful! Whaddaya think, ziggy? ;)

Perhaps, starting a line with "Property x:T.." and hitting enter can generate a getter, setter (Method x:Void(value:T)), and associated field (lcase and prefixed by underscore) all at once...