+1
> The problem with #ensure style selectors is that they are confusing because
> they both test something and maybe do something to create a certain
> condition. The only way to take away the confusion is to make a very long
> selector. That is why comments are also important.
>
> Like Stef
Am 25.10.2013 um 15:52 schrieb Sven Van Caekenberghe :
> The problem with #ensure style selectors is that they are confusing because
> they both test something and maybe do something to create a certain
> condition. The only way to take away the confusion is to make a very long
> selector. Tha
The problem with #ensure style selectors is that they are confusing because
they both test something and maybe do something to create a certain condition.
The only way to take away the confusion is to make a very long selector. That
is why comments are also important.
Like Stef said, this was a
Yes, I can understand the boring part of it
- this is a detail
- it's tiring to discuss small details to death
- some people speak more than act (me for example :)
But can we agree that
- details count
- critics count (convince yourself that they are not intended for bashing
people)
- and last one
On Oct 25, 2013, at 3:24 PM, Nicolas Cellier
wrote:
> What are real problems exactly?
Here is a list
- better API for Compiler
- better functionality for OPAL
- Cleaning Morph (architecture, package structure)
- using Slot for real
- Removing CodeHolder
We already discussed this API
it is in the bug tracker: ensureDelete, ensureDeleted….
So do what you want I personally want to focus on more important issues.
Once the full world will agree then do not forget to update the FileSystem
Chapter
that I wrote BTW (this is for the people complaining ab
Stef,
I really don’t want to stretch this into an argue …. but I have problems
understanding that. There are refactorings of method selectors because it is
said it is important that includesSubString: is written as includesSubstring:
and there are other examples. Now we have a selector that peo
What are real problems exactly?
If you are going to open each and every method to read the comment or the
code instead of trusting the name, IMHO that is going to be a real problem.
If the focus shall be on real problems, then why change APIs which are not
a real problem?
2013/10/25 Stéphane Duca
can we focus on real problems?
The method has a comment.
Stef
On Oct 25, 2013, at 10:39 AM, Norbert Hartl wrote:
>
> Am 25.10.2013 um 10:11 schrieb Nicolas Cellier
> :
>
>> So action=create object=directory
>> you want to be sure that you create a directory?
>> What if it already exists?
>>
Am 25.10.2013 um 10:11 schrieb Nicolas Cellier
:
> So action=create object=directory
> you want to be sure that you create a directory?
> What if it already exists?
> Since you want to be sure to create, will you erase and re-create?
> You see the kind of misunderstanding this could create...
>
So action=create object=directory
you want to be sure that you create a directory?
What if it already exists?
Since you want to be sure to create, will you erase and re-create?
You see the kind of misunderstanding this could create...
IOW, self ensureCreateMisunderstanding
2013/10/25 Stéphane Duc
Consistency
ensureActionObject
ensureCreateDirectory
ensureCreateFile
We discuss a lot with camillo when we did it and I think that this is good
right now.
> Out of curiosity, what was the motivation behind Issue 10924: Simplifying
> ensure* and create protocol?
>
> For me #ensureCreateDirecto
Out of curiosity, what was the motivation behind Issue 10924: Simplifying
ensure* and create protocol?
For me #ensureCreateDirectory is less intention revealing than
#ensureDirectory because the "ensure" means "create only if necessary", not
"definitely create" a directory. What am I missing? Than
13 matches
Mail list logo
