Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2009-06

with r13297 ChangeName has gone

4 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Paul Ishenin

Hello, FPC developers' list.

I think that ChangeName should stay in the TComponent class. It is the only way to change a component name without validation. Even if it is not used by Lazarus it is probably used by some third-party components. For example report generators can use them to implement own name validation and change for the designer objects (if they are components).

I suggest to make this method either virtual or dynamic (dynamic is better when a method will be seldomly/never overrided) and continue to use it. This way we can also monitor a name change inside TComponent descendants.

Best regards, Paul Ishenin.

Reply by email

Jonas Maebe
to Paul Ishenin: Hello, FPC developers' list. I think that ChangeName should stay in the TComponent…
Paul Ishenin wrote 6 lines
I think that ChangeName should stay in the TComponent class. It is the only way to change a component name without validation. Even if it is not used by Lazarus it is probably used by some third-party components. For example report generators can use them to implement own name validation and change for the designer objects (if they are components).

And the patch combines reformatting with functional changes, the commit comment does not mention what actually is changed nor why, and the patch changes at least some internal behaviour (the notifying of components from tcomponent.destroy now happens in the inverse order; this is unlikely to be part of the interface contract, but unless absolutely necessary it is bad to change such internal details since it can unnecessarily break existing programs).

Please Ivo, do not commit such changes without first asking whether your patch is ok if you are not the primarily responsible developer for that part of the FPC source tree (and split patches into reformatting and functionality changes, so that reviewing is easier, and explain in the comments what the patch changes).

Jonas

Reply by email

Ivo Steinmann
to Jonas Maebe

it was an accident removing it (or better uncomment it)

My Answer to the core liste:

This function wasn't actually to change in TComponent, I simply forgot to uncomment it again. Did some testings, and because it was nowhere used I didn't got an error and so I forgot to reenable it.

But there were several bugs in about 4 or 5 functions concerning freelists and handling them. And there was one bug in another function. Because all these were so obvious, that there's no need for discussion.

Formatting: so you are a friend of format changeings all few lines. Because I had to go through the whole code anyway I simply continued with the formatting that the first few functions started with.

Jonas Maebe wrote 30 lines
On 19 Jun 2009, at 04:23, Paul Ishenin wrote: > I think that ChangeName should stay in the TComponent class. It is > the only way to change a component name without validation. Even if > it is not used by Lazarus it is probably used by some third-party > components. For example report generators can use them to implement > own name validation and change for the designer objects (if they are > components). And the patch combines reformatting with functional changes, the commit comment does not mention what actually is changed nor why, and the patch changes at least some internal behaviour (the notifying of components from tcomponent.destroy now happens in the inverse order; this is unlikely to be part of the interface contract, but unless absolutely necessary it is bad to change such internal details since it can unnecessarily break existing programs). Please Ivo, do not commit such changes without first asking whether your patch is ok if you are not the primarily responsible developer for that part of the FPC source tree (and split patches into reformatting and functionality changes, so that reviewing is easier, and explain in the comments what the patch changes). Jonas _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email