Propose to depreciate childWithName+

[labordep]

Hi @tinchodias,
I propose to depreciate all BlElement>>childWithName+ methods because of multiples points :

• There are BlElement>>childWithId+ methods which are doing the same things
• The property is elementId
• Name is not the most common term to speak about an identification of a graphical element (but this point is subjective from my experience) and we prefer id which is most operationnal
• There are a lot of methods in BlElement and a little cleaning is good :)

Thanks for your feedback.

[plantec]

yes #childNamed: and #childWidthId: seem identical

[tinchodias]

I think your proposal is right.
Do you plan a PR?
there is a way to deprecate that also rewrites senders on runtime. This could be good in the case they are identical.

[labordep]

Ok no problem to do a PR.
Can you write here the way to depreciate and rewrite ? Thanks :)

[labordep]

@tinchodias I have tried to refactor some methods here : https://github.com/labordep/Bloc
But there is a problem and I don't know if this is a Pharo problem or a my bad.
I have writted some tests, for example BlElementTest>>testId and when I launch them (or others Bloc tests), that's freeze my Pharo image.
Can you check if you have same problem ? Thanks :)

[tinchodias]

Hi @labordep I of got the same image freeze!

My steps were: clone your repo on my Mac and run the build.sh script to install it.

Then I started to place halts and ended placing one at the first line of BlElementTest>>#setUp.

There first I noticed an exception in a debugger (wantsSteps blah blah) in the screenshot below, and I went to the Preferences to disable dialog warnings checkbox (I suspected this can help, but wasn't sure at all):

Then run again the test and the error was different:

At that point I realized the rewriting expression may require the argument (see inline comment in the repo). And yes, it was required. So now the test runs without freezing, but it fails: the id returned by the BlElement is not the Symbol but an BlElementId I think. The test fail message is confusing because the printString of the BlElementId is exactly like the Symbol. I'm not sure there what is the good solution, I let it to the author ;)

[labordep]

Thanks @tinchodias I will check that :)

[labordep]

I have created an issue for Pharo about this problem : pharo-project/pharo#12791

[MarcusDenker]

The issue tracker entry for Pharo uses #name on Class.. there is no way that this can work, as #name is called again in the debugger (or the exception).

[MarcusDenker]

wantSteps might be related to

pharo-project/pharo#12782

[MarcusDenker]

If I use this on a simple example

• I do see the wantSteps problem, we will fix it (but just press proceed)
• SyntaxError debugger opens, no problem. As expected, I close it, I can continue to work

It might be that you called this in a situation where the method with the error is called in a loop?

[labordep]

Possible, but how can I stop the loop to check that ?

[MarcusDenker]

You can't... it will allocate so much memory so fast that it just freezes.
Normally you can stop a recursiomn if you are fast. But this recursion tiggeres itself again with the cmd-dot: it wants to open a debugger, and that need #name, too.

Adding a DNU in #name is just not a good thing to do.

[labordep]

Thanks @MarcusDenker :)
If I understand, this code :

containerName
	<return: #Symbol or: nil>

	self
		deprecated: 'Use #id instead.'
		transformWith: '`@receiver containerName' -> '`@receiver id'.

	^ self id asSymbol

is not a good idea because id is used a lot by the system. This is a exception case, for others we will haven't this problems (except for very used methods names).

[MarcusDenker]

if you do it with a method that has lots and lots of calls (in a loop, maybe even another process), and you add an error there, you will have problems... this got a bit confusing as you used #name in Class in the other issue tracker: that method is better not to be touched, as it is used to print the exception when the DNU happens.

In the case of containerName I guess it is similar, a method that is used a lot while the system is running.

[labordep]

Yes I think container Name and id are very used, but normally it's should be not (this is another problem).

[tinchodias]

Hi, what happened with the associated code change?

[tinchodias]

Looking at usages of containerName and containerName:, I guess they are legacy from another time where they made sense, but now should really be deprecated and substituted.

[plantec]

ok :)

[tinchodias]

Was this issue closed by #207 ?

---

EDIT: I meant "Was this issue closed by #297 ?"

[labordep]

Was this issue closed by #207 ?

Yes!