I am trying to use synthesised accessors on a component on Lucee (although this issue seems to be the same on ColdFusion too).
Repro code:
// Person.cfc
component accessors=true {
property firstName;
property lastName;
function init(firstName, lastName){
variables.firstName = arguments.firstName;
variables.lastName = arguments.lastName;
}
}
And the calling code:
// person.cfm
person = new Person("Abigail", "Bowen");
writeDump(person);
Notice how I am not using the synthesised accessors here, I am purely setting the argument values into same-named variables-scoped variables.
However when I run this code, I see this:
Note how the properties have been populated. There's no problem with this, but I'm clearly not understanding how the accessors flag is supposed to work. I thought it was merely intended to synthesise some accessor methods for me (which it has), but that's all.
Also note that if I modify the CFC definition to not set accessors to true, then the dump shows this:
So no synthesised accessors (as expected), but also now the properties aren't even being displayed (with the variables-scoped values or not).
I don't really understand this conflation of "properties" and the accessors setting? Surely the accessors setting should only impact whether those accessor methods get created?
If I was only seeing this on one of the platforms, I'd probably put it down to a vagary of how writeDump() interprets the property definitions. But the behaviour is the same on ColdFusion 11, so it really does seem like there's some difference in behaviour I'm not quite getting.
Can anyone explain this? Are there any docs which explain it? If not... um... why not?
My underlying concern here is that the property values are not being stored "properly" and might cause me problems once I implement more of the code.
UPDATE:
At least on ColdFusion, it seems to be just a change in writeDump()'s behaviour, because if there are getters for the properties (whether or not the accessors flag is set) then the property values start showing up in the dump. This is not the case on Lucee though, so there's still a question mark there.
For the sake of full disclosure, this question is a summary of a question I also asked on my blog ("CFML: trying to understand accessors"). The duplication is intentional as my blog gets a different audience from that of this site.
Without accessors=true, the property declarations are just metadata.
With accessors=true, the property declarations trigger the generation of getters / setters and thus a property is both a variables scope item and a pair of methods.
In your constructor, you assign to the variables scope items -- which would be the same as using the generated setters -- and when CFML dumps the component, it sees the property metadata and the generated getters and so it displays the values those properties have (since it can easily and safely call the generated getters).
This came up with ACF9. Until then the definition in the property docs was right: cfproperty declarations are just metadata. (see dump(getMetaData()).
In ACF9 this was not fully correct anymore for 3 reasons:
With accessors=true a getter and setter is generated for each property and those accessors read from and write to the variables scope. Cfproperty is not just metadata anymore, but has a direct effect on the behaviour of the instance. I like to think about it as the CF version of real OO properties (introduced by accident).
The cfdump implementation changes its behaviour based on the property declarations. If property name; is defined and method getName() exists (generated or implemented) it is added to the property section of the dump.
The property attributes control the ORM.
Since I got to know those features, I design all my (public) CFCs to look right when dumped, eg. I only use the property declaration (+ getters) when I want to have it visible. In addition, you can implement methods that are only called by the dumps and cost nothing on instantiation:
struct function getDebug(){
var x = doSomethingExpensive();
return { "Foo":f, "Bar":b, "Baz":x };
}
//or for a user iterator
string function getName(){
return qUsers.name[index];
}
Some caveats I know:
ACF always calls the getters from the dumps, while in Railo/Lucee the value from the variables scope is shown. Thus, the above examples (getDebug()and getName()) don't work on Railo/Lucee.
If the getter is not public or results in an error, the dump shows an empty string for the property (not sure here, maybe the property is missing instead).
Property declarations in extended CFCs are ignored. This gave me some headache in ORM entities that use inheritance, because you are not allowed to declare a property twice. Thus, you have no possibility to show a property that is defined in a base CFCs.
Railo/Lucee seems to ignore the property types. All accessor accept and return only strings (see getMetaData()).
Minor: In ACF when you activate the accessors, but deactivate getter and setter for a property: property name="user" getter="false" setter="false"; it is still visible in the dump - it should be hidden.
Related
I want to use derived attributes and references in an ecore model, but so far I have not found any documentation on how to set the code for the methods which compute the values of derived attributes/references.
As far as I understand it, the basic workflow is to mark an attribute/reference as derived, generate model code, and then manually add the implementation. However, I work with models dynamically generated through the Ecore API. Is there a way to take a String and specify this String as the implementation for the computation of the derived feature, without manually editing generated files?
EDIT>
To clarify: I'm looking for a way to directly change the generated Java files, by specifying method bodys (as strings) for the getters of derived EStructuralFeatures.
EMF provides a way of dealing with dedicated implementation for EOperation and derived EAttribute using "invocation delegate". This functionality allows you to put some implementation directly in your ecore metamodel in a string format (as soon as the used language can be "handled" by EMF, i.e, an invocation delegate exists).
As far as I know, OCL is well supported: https://wiki.eclipse.org/OCL/OCLinEcore#Invocation_Delegate
The registration of the invocation delegate is performed either by plugin registration or by hand (for standalone usage), and the mechanism works with the EMF reflection layer (dynamic EMF): https://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Registering_an_Invocation_Delegate
(Please note that I never experienced this mechanism. I know it exists, but I never played with it.)
EDIT>
It seems that the question was not related to dynamic code execution for derived attribute, but to code injection (I misunderstood the "Is there a way to take a String and specify this String as the implementation for the computation of the derived feature?").
EMF provides a way of injecting code placed on the ecore metamodel directly into the generated code.
Here is the way for EAttribute with derived property. The EAttribute should have the following properties set to true: {derived volatile} (you can also add transient). If you only want a getter and no setter for your EAttribute, you can also set the property changeable to false.
Once your EAttribute is well "configured", you have to add a new EAnnotation with the source set to http://www.eclipse.org/emf/2002/GenModel and an entry with the key set to get and value set to your code that will be injected (see image below).
And voilà, your code will be generated with the value value injected in your getter.
You can add the same process for EOperation using body instead of get.
In Ember, defining a property as a computed alias to another property (or another object's property) using Ember.computed.alias('otherProperty') seems to have basically the same result as defining it as a binding to that property using propertyNameBinding: 'otherProperty'.
I've looked at the source and the documentation but I can't find any reason why one would be preferred over the other. Obviously templates use bindings, which is fine, but for properties in e.g. controllers, or for referencing a controller's property on a view, is there a difference?
An alias can be overwritten on extend(), completely eliminating the relationship with the other key.
A brief example: I have a class of time-related functions and classes, and the classes have both a unit property (for Day, Minute, etc) and a precision property. Normally these are functionally identical. In one or two classes they diverge. Ember.computed.alias allows precision to alias to unit for most cases, but to be overridden with its own value as needed.
Note that create() will use the alias setter, instead of overriding.
Also, setting an alias with a null object in its path can blow up, while a binding will simply not sync if the path doesn't lead anywhere.
Please see morgoth's comment below per soft-deprecation of *Binding syntax
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Function_Names#Function_Names
Regular functions have mixed case; accessors and mutators match the
name of the variable: MyExcitingFunction(), MyExcitingMethod(),
my_exciting_member_variable(), set_my_exciting_member_variable().
Isn't it the whole point of encapsulation to hide implementation details from the user so he/she is not aware of whether the accessor/mutator method returns/modifies a member variable or not? What if I change the variable name or change the way it's stored inside the object?
EDIT:
If I have an instance variable int foo_ it seems straightforward
int foo() const { return foo_; }
but if I add another method that returns foo_ + 2, should I name if bar or GetBar?
int bar() const { return foo_ + 2; }
int GetBar() const { return foo_ + 2; }
If I choose GetBar and later decide to cache the returned value in another member variable bar_, will I have to rename the method to bar?
Actually, the point of encapsulation is to hide the inner workings of a class, not necessarily to hide the names of things. The name of the member variable doesn't matter; it's the level of indirection that the accessor or mutator provides.
Having an accessor gives you the ability to change the inner workings of the class (including the names of member variables) without breaking the class's interface with the outside world. The user of the class need not concern himself with implementation details, including what things are named inside the class, but only on the behavior of the class, as seen from the outside.
To put it another way, users of a class should not rely on Google's style guide to determine whether or not they are modifying a member variable.
Because google style guide is only meant to be followed by google employees. Rather - it's not that good of a style guide.
Case in point - they explicitly ban passing by non-const reference because it can be "confusing".
So you're right, it defeats the purpose of encapsulation. Don't guide yourself by it.
When considering a class, it may conceptually have visible
state, which can be accessed by the client. How this state is
represented inside the class is another matter, and that's what
accessors (getters and setters) hide. My own naming convention
also makes this distinction: if the function is conceptually
a getter or a setter, it has the name of the attribute, which
would normally be a noun; otherwise, it is a verb. And
I distinguish between cases where the function is getting or
setting something which isn't conceptually part of the class
(e.g. which partially depends on an argument), which have the
verb get or set in their name, and the case where the
function is actually modifying what is conceptually an
attribute, in which case they don't.
For the rest, like most style guides, not everyone is in total
agreement with this one. I'm not sure I like their naming
conventions, for example. They're called naming conventions
because they are just that: arbitrary conventions. The only
real hard rule is that types, macros and other things must be
distinguished, and that names should never start or end with an
underscore. (There are also some softer rules: I'd be very
suspicious of a convention which ended up making the names of
local variables longer than those of globals.)
I may be taking an assumption of common sense too far, but I'm pretty sure that retaining a published interface takes precedence over following the naming guide.
Since your original bar / GetBar function is not an accessor, I presume it should follow the regular name guide and be called GetBar.
If you later introduce bar_ so that in some sense the function becomes an accessor, I'm pretty sure you should not remove GetBar. I suppose you could add a function bar() as well, defined to do the same thing, but I don't think I'd interpret the style guide to require that.
I'm also pretty sure that as soon as your published interface includes functions that you (and callers) think of as "accessors", encapsulation is in any case out the window to some extent, because you're talking about the state of the object instead of its behavior. Just because a function returns the value of a member variable in the current implementation does not mean that it has to be documented as an accessor. But if you do insist on writing functions that are publicly recognized as accessors, Google tells you how to name them. The classic example is that a sufficiently dumb data record object might reasonably have accessors, since the whole class is publicly defined to be a bundle of fields with maybe a little bit of behavior.
I've read that style guide a few times before, but I have never worked for Google so I'm not privy to how their code reviews tend to apply it in practice. I should think that an organization that size cannot be wholly consistent in every detail. So your guess is probably as good as mine.
I've read a lot of guides that explain why I should use "private" and the answer is always "Because we don't want anyone else setting this as something". So, let me ask the following questions:
Assuming that I want to have a variable that is set-once (perhaps something like a character name in a video game, ask once, then it's set, and then you just use the get variable(edit:function) for the rest of the game) how do I handle that one set? How would I handle the get for this as well?
What is the actual advantage of using a private access modifier in this case? If I never prompt the user to enter the name again, and never store information back to class.name shouldn't the data remain safe (moderately, assuming code works as intended) anyways?
I hope someone will help me out with this as the explanations I've googled and seen on here have not quite put my thoughts to rest.
Thanks!
The access specifiers mainly serve to denote the class interface, not to effectively limit the programmer's access or protect things. They serve to prevent accidental hacking.
If something is set once, then you should try to set it when it is created, and make it const.
If the interface doesn't need to be especially clear (for example, if few people need to learn it) then it doesn't make sense to spend effort engineering it. Moreover changes that don't make much difference in how the interface is used can be applied later. The exposed variable can be changed to a getter/setter using simple search-and-replace.
If it were a published binary interface, then you would want to get it right the first time. But you're just talking about the internals of your program.
And it's fairly unlikely that anyone will reset the player name by accident.
I won't try to justify the private set method as that sounds a bit weird to me. You could handle the one set by using a friend declaration. But then why would you define a setter when the friend could just set the value directly?
I generally avoid setters if I can at all manage it. Instead I prefer provide facility to set member variables via the constructor. I am quite happy to provide getters if they make sense.
class player_character_t {
std::string name_;
public:
player_character_t(std::string const& name)
: name_ (name)
{
}
std::string const& name() const { return name_; }
};
This forces you to delay construction of the object until you have all the information you require. It simplifies the logic of your objects (ie they have a trivial state diagram) and means you never have to check is something is set before reading it (if the object exists, it is set properly).
http://en.wikipedia.org/wiki/State_diagram
Marking things as private helps prevent accidents. So when you make a mistake and it is no longer the case that the "code works as intended" the compiler may help you detect it. Likewise const can be a big help in detecting when you are using objects incorrectly.
It's that last parenthetical that is important: assuming code works as intended.
In my mind it's similar to permissions in Linux systems. You know the root password and you can delete any file, but you don't stay logged in as root so you don't do anything by accident. Similarly, when you have a private variable characterNameString, and someone (or you) later tries to give it a new value, it will fail. That person will have to go look at the code and see that it's marked private. That person will have to ask themselves "why is this private? Should I be modifying it? Should I be doing this another way?" If they decide they want to, then, they can. But it prevents silly mistakes.
Don't confuse the private and the public interfaces of the class. In theory these are completely different interfaces, and this is just a design feature of C++ that they're located physically in the same class declaration.
It's perfectly ok to have a public getter/setter when the object property should be exposed via the public interface, so there is no rule such as 'setter is always private'.
More on that topic in the (More) Exceptional C++ books by Herb Sutter. It's an absolutely neccessary reading for someone who wants to understand C++ and be proficient with it.
If you have doubts over deciding whether to use getter/setters over the class variables, there are numerous explanations on the internet why getters/setters are better.
If the variable is 'write once then forever read only' I'd recommend making it a const member that is initialized during construction. There's no value in a private 'setter' function because it won't be used. Also you avoid people using the setter function to set the name when it's never meant to be set.
For example:
class Player
{
private:
const std::string m_name;
public:
Player(const std::string& name) : m_name(name) {}
};
Private getters and setters all make sense when the data in question involves several variables, have additional constraints you want to make sure you adhere to, and these operations are done several times in your class. Or when you plan further modifications to the data model and wish to abstract operations on the data, like using std::vector but planning to make it std::map or similar cases.
For a personal example, I have a smart pointer implementation with a private reset(T*, int*) method that is essentially a setter for the stored object and its reference count. It handles checking validity of objects and reference counts, incrementing and decrementing reference counts, and deleting objects and reference counts. It is called eight times in the class, so it made perfect sense to put it into a method instead of just screwing around with member variables each time, slowing programming, bloating code and risking errors in the process.
I am sure private getters can also make sense if you are abstracting the data from the model and/or you have to implement error checking, for example throwing instructions if the data is NULL instead of returning NULL.
I personally find it weird/ugly when a class uses a getter to access its own member data. I know the performance impact is none but I just don't like to see all those method calls.
Are there any strong arguments either way, or is it just one of those things that's personal preference and should be left to each coder, or arbitrarily controlled in a coding standard?
Update: I'm meaning simple getters, specifically for a class' non-public members.
The reason you might want to use a getter/setter is because it conceals the implementation. You won't have to rewrite all of your code if you are using getters/setters in case the implementation does change, because those members can continue to work.
EDIT based on the many clever comments:
As for a class using setters and getters on itself, that may depend on the particulars. After all, the implementation of a particular class is available to the class itself. In the cases where a class is normally instantiated, the class should use the member values directly for its own members (private or otherwise) and its parent classes (if they are protected) and only use getters/setters in the case that those members are private to the parent class.
In the case of an abstract type, which will usually not contain any implementation at all, it should provide pure virtual getters and setters and use only those in the methods it does implement.
Willingness to use getters/setters within class member implementation is the canary in the mine telling that your class is growing unreasonably. It tells that your class is trying to do too many different things, that it serves several purposes where it should serve one instead.
In fact, this is usually encountered when you are using one part of your class to store or access your data, and another part to make operations on it. Maybe you should consider using a standalone class to store and give access to your data, and another one to provide a higher view, with more complex operations with your data.
THE OBVIOUS
getters and setters for protected members makes as much sense as for public... derived classes are just another form of client code, and encapsulating implementation details from them can still be useful. I'm not saying always do it, just to weight pros and cons along the normal lines.
getters and setters for private members is rarely a net benefit, though:
it does provide the same kind of encapsulation benefits
single place for breakpoints/logging of get/set + invariant checks during dev (if used consistently)
virtual potential
etc...
but only to the presumably relatively small implementation of the same struct/class. In enterprise environments, and for public/protected member data, those benefits can be substantial enough to justify get/set methods: a logging function may end up having millions of lines of code depedent on it, and hundreds or thousands of libraries and apps for which a change to a header may trigger recompilation. Generally a single class implementation shouldn't be more than a few hundred (or at worst thousand) lines - not big or complex enough to justify encapsulating internal private data like this... it could be said to constitute a "code smell".
THE NOT-SO OBVIOUS
get/set methods can very occasionally be more readable than direct variable access (though more often less readable)
get/set methods may be able to provide a more uniform and convenient interface for code-generated member or friend methods (whether from macros or external tools/scripts)
less work required to transition between being a member or friend to a freestanding helper function should that become possible
implementation may be rendered more understandable (and hence maintainable) to people who're normally only users of the class (as more operations are expressed via, or in the style of, the public interface)
It's a bit out of scope for the question, but it's worth noting that classes should generally provide action-oriented commands, event-triggered callbacks etc. rather than encouraging a get/set usage pattern.
It seems most people didn't read your question properly, the question is concerning whether or not class methods accessing its own class' members should use getters and setters; not about an external entity accessing the class' members.
I wouldn't bother using getter and setter for accessing a class' own members.
However, I also keep my classes small (typically about 200-500 lines), such that if I do need to change the fields or change its implementations or how they are calculated, search and replace wouldn't be too much work (indeed, I often change variable/class/function names in the early development period, I'm picky name chooser).
I only use getter and setters for accessing my own class members when I am expecting to change the implementation in the near future (e.g. if I'm writing a suboptimal code that can be written quickly, but plans to optimize it in the future) that might involve radically changing the data structure used. Conversely, I don't use getter and setter before I already have the plan; in particular, I don't use getter and setter in expectation of changing things I'm very likely never going to change anyway.
For external interface though, I strictly adhere to the public interface; all variables are private, and I avoid friend except for operator overloads; I use protected members conservatively and they are considered a public interface. However, even for public interface, I usually still avoid having direct getters and setters methods, as they are often indicative of bad OO design (every OO programmers in any language should read: Why getter and setter methods are Evil). Instead, I have methods that does something useful, instead of just fetching the values. For example:
class Rectangle {
private:
int x, y, width, height;
public:
// avoid getX, setX, getY, setY, getWidth, setWidth, getHeight, setHeight
void move(int new_x, int new_y);
void resize(int new_width, int new_height);
int area();
}
The only advantage is that it allows changing internal representation without changing external interface, permitting lazy evaluation, or why not access counting.
In my experience, the number of times I did this is very, very low. And it seems you do, I also prefer to avoid the uglyness and weightyness of getter/setters. It is not that difficult to change it afterwards if I really need it.
As you speak about a class using its own getter/setters in its own implementation functions, then you should consider writing non-friend non-member functions where possible. They improve encapsulation as explained here.
An argument in favor of using getters is that you might decide one day to change how the member field is calculated. You may decide that you need it to be qualified with some other member, for instance. If you used a getter, all you have to do is change that one getter function. If you didn't you have to change each and every place where that field is used currently and in the future.
Just a crude example. Does this help?
struct myclass{
int buf[10];
int getAt(int i){
if(i >= 0 && i < sizeof(buf)){
return buf[i];
}
}
void g(){
int index = 0;
// some logic
// Is it worth repeating the check here (what getAt does) to ensure
// index is within limits
int val = buf[index];
}
};
int main(){}
EDIT:
I would say that it depends. In case the getters do some kind of validation, it is better to go through the validation even if it means the class members being subjected to that validation. Another case where going through a common entry point could be helpful is when the access needs to be essentially in a sequential and synchronized manner e.g. in a multithreaded scenario.
Protecting a member variable by wrapping its access with get/set functions has its advantages. One day you may wish to make your class thread-safe - and in that instance, you'll thank yourself for using those get/set functions
this is actually for supporting the object oriented-ness of the class by abstracting the way to get(getter). and just providing its easier access.
Simple answer. If you are writing a one shoot program, that will never change, you can leave the getters at peace and do without any.
However if you write a program that could change or been written over time, or others might use that code, use getters.
If you use getters it helps change the code faster later on, like putting a guard on the property to verify correctness of value, or counting access to the property(debugging).
Getters to me are about easy possibilities(free lunch). The programmer who write the code does not need getters, he wants them.
hope that help.
My thoughts are as follows.
Everything should be static, constant, and private if possible.
As you need a variable to be instanced meaning more than one unique
copy you remove static.
As you need a variable to be modifiable you remove the const.
As you need a class/variable to be accessed by other classes you remove
the private.
The Usage of Setters/Getters - General Purpose.
Getter's are okay if the value is to ONLY be changed by the class and
we want to protect it. This way we can retrieve the current state of
this value without the chance of it's value getting changed.
Getter's should not be used if you are planning to provide a Setter
with it. At this point you should simply convert the value to public
and just modify it directly. Since this is the intent with a Get/Set.
A Setter is plain useless if you are planning to do more then simply
"this.value = value". Then you shouldn't be calling it "SetValue"
rather describe what it is actually doing.
If let's say you want to make modifications to a value before you
"GET" it's value. Then DO NOT call it "GetValue". This is ambiguous
to your intent and although YOU might know what's happening. Someone
else wouldn't unless they viewed the source code of that function.
If let's say you are indeed only Getting/Setting a value, but you are
doing some form of security. I.e. Size check, Null Check, etc.. this
is an alternative scenario. However you should still clarify that in
the name E.g. "SafeSetValue" , "SafeGetValue" or like in the "printf"
there is "printf_s".
Alternatives to the Get/Set situations
An example that I personally have. Which you can see how I handle a
Get/Set scenario. Is I have a GameTime class which stores all kinds
of values and every game tick these values get changed.
https://github.com/JeremyDX/DX_B/blob/master/DX_B/GameTime.cpp
As you will see in the above my "GETS" are not actually "GETS" of
values except in small cases where modification wasn't needed. Rather
they are descriptions of values I am trying to retrieve out of this
GameTime class. Every value is "Static Private". I cannot do Const
given the information is obtained until runtime and I keep this
static as there is no purpose to have multiple instances of Timing.
As you will also see I don't have any way of performing a "SET" on any of this data, but there are two functions "Begin()" and "Tick()" which both change the values. This is how ALL "setters" should be handled. Basically the "Begin()" function resets all the data and loads in our constants which we CANT set as constants since this is data we retrieve at runtime. Then TICK() updates specific values as time passes in this case so we have fresh up to date information.
If you look far into the code you'll find the values "ResetWindowFrameTime()" and "ElapsedFrameTicks()". Typically I wouldn't do something like this and would have just set the value to public. Since as you'll see I'm retrieving the value and setting the value. This is another form of Set/Get, but it still uses naming that fits the scenario and it uses data from private variables so it didn't make sense to pull another private variable and then multiply it by this rather do the work here and pull the result. There is also NO need to edit the value other then to reset it to the current frame index and then retrieve the elapsed frames. It is used when I open a new window onto my screen so I can know how long I've been viewing this window for and proceed accordingly.