The classic Case bug

Jan C de Graaf

And that's why I like (against general popularity) the following notation:

public MyClass(int p_intID, ..., bool p_blnIsUpdate)

Nemanja Trifunovic

Have I mentioned that properties are evil?

Programming Blog utf8-cpp

J a a n s

Stack overflow exception :confused: I need to increase the ram...;P

*jaans

V 0

That's why I very rarely put capitals in my variable naming... ;P

V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive

ChandraRam

V. wrote:

That's why I very rarely put capitals in my variable naming...

whatifyouneedareallylongvariablenamethen ;P :)

Chris Maunder

:confused:

cheers, Chris Maunder

CodeProject.com : C++ MVP

V 0

what_if_you_need_a_really_long_variable_name_then or wiynarlvnt fact is it always worked for me ;-)

V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive

Paul Conrad

My thoughts, too.

"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon

Nemanja Trifunovic

If you invoke a function call with a syntax for accessing a variable, sooner or later you will invoke a function when you really wanted to access a variable.

Programming Blog utf8-cpp

Chris Maunder

I find that a terrible justification. Write your properties correctly and safely and without side effects and use properties instead of variables and you will not only be fine, but you will also have provided yourself that little bit of future proofing that Properties provide.

cheers, Chris Maunder

CodeProject.com : C++ MVP

Nemanja Trifunovic

Chris Maunder wrote:

Write your properties correctly and safely and without side effects and use properties instead of variables and you will not only be fine, but you will also have provided yourself that little bit of future proofing that Properties provide.

I don't write public variables (except for POD types). What I am arguing here is that the function syntax is much better for something that is really a function. Ie, I find much easier to understand this:

dialog.SetFont(font);

than:

dialog.Font = font; // looks like accessing a public variable, when it is really a function call

Not to mention all these cases when you try to set a member variable internaly, mix the case and get a stack overflow :rolleyes:

Programming Blog utf8-cpp

Mladen Jankovic

Nemanja Trifunovic wrote:

Not to mention all these cases when you try to set a member variable internaly, mix the case and get a stack overflow

Maybe different naming convention is better solution then avoidance of properties. With the significant code base it's not possible to change it, but then again it's your (or somebody else's) mistake made at the beginning of the project and not the fault of properties.

Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. (Charles M Strauss)

Nemanja Trifunovic

Mladen Jankovic wrote:

then again it's your (or somebody else's) mistake made at the beginning of the project and not the fault of properties.

Sure. All I am saying is that properties are "too much abstraction" and easily add confusion. If something is a function, it should be invoked as a function, IMHO. Uzgred, cestitam na proslomesecnom clanku :)

Programming Blog utf8-cpp

peterchen

Because coding doesn't end after a single SetFont statement. First, because I have to do that thousand times over and over, until a project is done. Because in a lengthy expression, every additional set of parantheses hurts readability. q = v.Mag*complex(cos(v.Phase),-sin(v.Phase))/c.Ref is closer to the problem domain description than SetQ(v.GetMag()*complex(cos(v.GetPhase(),-sin(v.Phase())/c.GetRef()) (I assume you agree that being close to the problem domain is a good thing)

We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist

Mladen Jankovic

Nemanja Trifunovic wrote:

Uzgred, cestitam na proslomesecnom clanku

Hvala! :beer:

Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. (Charles M Strauss)

Nemanja Trifunovic

peterchen wrote:

I assume you agree that being close to the problem domain is a good thing

I agree. However, I am not sure I agree that additional parenthses move you away from the problem domain. In fact, your example just illustrates well what I mean by "too much abstraction". v.Phase does not look as a function call, and yet it is, and there are no restrictions what can happen within that function and how long it may take. That's my main problem with the properties.

Programming Blog utf8-cpp

peterchen

I see your point. A LinkedList.Size that runs through the entire list to count them would be wrong. A property should be a property only if it runs in linear time and has none or "obvious" side effects (e.g. changing rect.width would obviously have the side effect of changing rect.right). I'd even make some room here for dependent values that need to be cached due to long calculation: it should run in linear time most of the time. But I agree that this is debatable. Less technically, it should be only a property if it acts like a property. As for proximity to the problem domain - it depends. I am dealing with lots of very specific numeric processing based on physical models, i.a.W. adding, multiplying, dividing, rooting and general mutilation of hundreds of values. Using short names close to the mathematical formulation is essential here to keep source and spec comparable.

btw. did you spot the parenthesis error I sneaked into the second snippet of my previous post? :cool:

We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist

Nemanja Trifunovic

peterchen wrote:

As for proximity to the problem domain - it depends. I am dealing with lots of very specific numeric processing based on physical models, i.a.W. adding, multiplying, dividing, rooting and general mutilation of hundreds of values. Using short names close to the mathematical formulation is essential here to keep source and spec comparable

I don't find C syntax very good for math-heavy work, and overuse of parantheses is one of the main reasons for that. Even good ol' Fortran is better. In fact, C syntax sucks in general - why do all these "new" and "clean" languages keep it when they don't aim for the source-level compatibility with C?

peterchen wrote:

btw. did you spot the parenthesis error I sneaked into the second snippet of my previous post?

Not until you mentioned it :)

Programming Blog utf8-cpp

supercat9

In fact, your example just illustrates well what I mean by "too much abstraction". v.Phase does not look as a function call, and yet it is, and there are no restrictions what can happen within that function and how long it may take. That's my main problem with the properties. Although languages don't enforce any requirement that the use of 'read' properties be limited to values that can be computed in constant (not linear!) time, nor any requirement that the value written to a property have any relation to what may be later read back, that doesn't mean that people shouldn't follow such rules when using properties. I will say that a fair number of classes in .net abuse properties IMHO. For example, I would consider StringBuilder.Length to be a fine read-only property. I do not believe it should be writable. Changing the length of a string should require a method, since doing so has a side effect of affecting the contents. BTW, I wish there were a syntax in vb.net for two very common property templates. Something like:

Friend Property Foo As Integer Using(_Foo)
Refresh
End Property

as shortcut for

Friend Property Foo As Integer
Get
Return _Foo
End Get
Set(value as Integer)
_Foo = value
Refresh
End Set
End Property

I would guess that the majority of all properties have get and set routines that do nothing except return or set a field, and a majority of the rest have a get routine that returns a field and a set routine that sets a field and then performs an update. It shouldn't be necessary for the most common case to take eight lines of code.

Lost User

Glad I don't have to maintain your code!

Take a chill pill, Daddy-o .\\axxx (That's an 'M')