World: r3wp

Only modifying or action functions should have verbs, not all functions. 
The *-OF convention comes from English, not C.

This decision came out of the early R3 project a few years ago, back 
when you were still taking a break from REBOL :)

In the case of your faces question, "faces" is a collective noun, 
and in function form is a request for a property or contents of its 
argument (don't know which), so FACES-OF would probably be preferred, 
leaving the 'faces word available to be used as a variable. Or GET-FACES 
if you prefer to emphasize the action of retrieving that value and 
have a corresponding SET-FACES function.

I added my two cents to the CC discussion.

Look at my reply :)

Some *? functions that might be better off as *-OF: ENCODING?, FILE-TYPE?, 
INDEX?, LENGTH?, SIGN? and SIZE?. Except for the first two the old 
names would need to stick around because of the legacy naming rules. 
Strangely enough, UTF? is OK because it is short for "UTF what?". 
The series contents functions have an implicit -OF :)

INFO? is iffy because "info" is not an adjective and makes a poor 
question word, but it can be used in a conditional context (it returns 
none if there is no info) and the legacy naming rule applies so it's 
probably not worth adding INFO-OF.

I'd be willing to let the series actions that return contents to 
continue to have the -OF be implicit, especially since they are legacy 
:)

And HEAD and TAIL can still have -OF be implicit too, IMO.

I think to,  I think the rule is most usefull in cases like bind 
where we need multiple variants of a word to mean different things. 
  in such a case, the  ? should always tend toward the most obvious/usefull 
conditional safe function.   :-)

(even if it does return a value instead of true)

for example, I feel that binding?  would have been a much better 
word than bind?

since we understand that if something has a value, we might as well 
receive the value instead of just knowing that this is true.

Sounds excellent, Brian

This is one of those weird circumstances where I know the answer 
to the question because I was there when the original decision was 
made. The reflectors (the *-OF functions that call REFLECT) were 
my idea in the first place, as a security measure, though obviously 
Carl wrote them and came up with the nouns :)

The word "binding" is two different nouns (one referring to the act 
of binding, one referring to the result of binding), so it doesn't 
fit the adjective? model very well. The word "bound" is the adjective 
form. See http://issue.cc/r3/1819for details.

this naming convention doesn't work with MAXIMUM-OF and MINIMUM-OF, 
which don't actually return the maximum or minimum of a series, they 
return the series at the position of the maximum or minimum. Gregg 
has suggested that these be renamed to FIND-MAX and FIND-MIN instead, 
and this will probably happen (rarely used, really badly named). 

 - I have got absolutely no problem with MAXIMUM-OF or MINIMUM-OF, 
 FIND-MAX and FIND-MIN aren't any better, because they express the 
 same, just in a less fortunate way (find is less descriptive than 
 maximum/minimum)

To describe something else we would need to use something line INDEX-OF-MAXIMUM?, 
which is more accurate, but unnecessarily long to my taste

It is a good idea to only use noun-of for intrinsic properties, rather 
than contents of container types.

 - it looks to me that you suggest, that for you, the preferable way 
 is:

    faces? face

, and not

    faces-of face


As far as I am concerned, I used the convention as written now, but, 
probably, the majority of users prefer the latter.

(in this specific case)

Or, to be even more accurate with the MAXIMUM-OF replacement, I should 
have mentioned POSITION-OF-MAXIMUM?, which is even longer

I do not think, that the name of a function should describe everything, 
so, if I really want to get the maximal of the values in a series, 
I can be content to know that the MAXIMUM-OF function exists and 
be prepared to read the doc string what it actually does.

Aren't those more like AT-MAXIMUM and AT-MINIMUM ?

that looks more descriptive

you should add it to the above CC ticket as your proposal, I guess

or, if you do not want to, I can do it

Done.

Yeah, that "intrinsic properties" is the softest part of the rule, 
and only really applies to core mezzanines. It is a little more accurate 
to say that for the container access functions that are in core, 
which are *all* legacy functions, the -of is implicit. If the alternative 
is putting a ? on the word, definitely use -of instead for new functions 
if they aren't for use in conditional contexts, or in some other 
way are a question.

I'll edit the comment accordingly.

The choice isn't between FACES? and FACES-OF, it's between FACES-OF 
and FACES.

And it wouldn't be INDEX-OF-MAXIMUM?: First of all, the ? is inappropriate, 
secondly, it returns the series, not the index. FIND-MAX isn't less 
descriptive because it references the behavior of MAX (which we have 
already learned means maximum) and FIND (which we know returns the 
argument series at the position of the thing found). We don't only 
get our conceptual context from English, we also get it from the 
rest of REBOL.

ChristianE, AT-MAXIMUM and AT-MINIMUM are much better, I'll relay 
that suggestion.

Guys, anyone knows if this was discussed as 'intended behaviour' 
by Carl or looks like inconsistency/bug to you?

>> a: make object! [b: []]
== make object! [
    b: []
]

>> c: make a []
== make object! [
    b: []
]

>> d: make a make object! []
== make object! [
    b: []
]

>> same? a/b c/b
== false

>> same? a/b d/b
== true

The choice isn't between FACES? and FACES-OF, it's between FACES-OF 
and FACES.

 - actually, not. The FACES? word is the one used now, which is created 
 in accordance with the current function naming wording, since we 
 defined a function collecting the faces contained in a panel.

Cyphre, Something never tried before can't be categorized as a bug.
It's a feature :-)

well, in R2 'copies' in both cases..so its either intended change 
in R3 or bug

>> d: make a make object! []
same behavior than 
>> d: append make object! [] a

But I agree, it's quite unexpected.

my mistake, same as
>> d: copy a

I vote for inconsistent.
>> make object! object! 
Should that be allowed, to begin with ?

It was allowed in R2 so why not?

Never saw that before. I don't understand the expected behavior to 
begin with.

http://www.rebol.com/docs/changes-2-5.html#section-85

Hum ok, it's cleared stated then. It's a feature

*clearly

R2 session:
>> a: make object! [b: []]
>> c: make a []
>> d: make a make object! []
>> same? a/b c/b
== false
>> same? a/b d/b
== false


So if this was changed in R3 I'm asking if it was intended or not. 
I don't care much what is the 'right' way but asking mainly because 
if the change was intended it should be well noted and documented 
otherwise it can make headache to people.

OH, I see your point now.

I think it's a bug now, It's doing the reverse of the R2 behavior.
>> d: make a make object! []
R3 reverse the parameters at some point and performs 
>> d: make object! [] a

inconsistent anyway

the difference I was pointing out is:


make <object> <block> ;copies the block values inside the prototype 
object

while


make <object> <object> ;doesn't copy the block values in prototype 
object

that is in R3...in R2 it was consistent

yeah it's what I understood