Feature #4984: [TERMINOLOGY] Provide Document for Terminology (e.g. "Global Status")

• Status: Rejected
• Assignee: -
• Target version: -

[lazaridis.com (Lazaridis Ilias)]

=begin

In order to avoid communication barriers, a document containing basic terminology should be provided (ideally directly within the source-code tree).

As an example (based on an communication problem within issue #4893), this issue here attempts to define the meaning of "Global Status" (Global State) and "Local Status" (Local State), thus the result can be included in the document.

Note that this is not language-specific, thus any existent standard definition should be used. A small overview, without any references to existent documentation:

• Global Status (synonym: Global State)
  • Example 1: $call_string_initialize = true|false
    • This is a global status, bound to a global variable, which is accessed directly
    • A thread which would introduce it's own String-class-object instance, would override the behaviour of another thread
  • Example 2: String.call_initialize = true|false
    • using internally "static int call_initialize"
    • This is still a global status, bound to a translation-unit (string.c) variable
  • both examples work, if only one String-class-object is available
  • both examples would fail, if a program would produce somehow a 2nd String-class-object (e.g. within a thread)

• Local Status (synonym: Local State)
  • String.call_initialize = true|false
  • Using internally a class variable (either @@call_initialize_flag, or a C-low-level-flag, e.g. FL_USER18)
    • This is a class-local-status, bound to a class variable
      "global status").
    • A thread which introduces in any way it's own String class, would not override the behaviour of the global string class, but only it's own, because "call_initialize" is a "Local Status".
  • IMPORTANT:
    • The message can be sent to the (String class) object everywhere where the String class is visible (= globally)
      • This fact does not make "call_initialize" a "global status" (otherwise any behaviour of class String would be

=end

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Rejected

=begin
I am sorry but I don't understand what you mean by this issue. Both global status and local status has String.call_initialize in examples. Contradicting proposals should be rejected, until the OP make it clear. By the way, any behavior of String class is global status. I don't prohibit global status. But adding new ((modifiable)) global status should be done carefully.

In addition, you state "thread introduces its own String class", but that's not how classes works in the language. You have to understand the semantics of the language before forcing us to adapt your understanding and expectation of the language-should-be, before making proposals.

matz.
=end

[lazaridis.com (Lazaridis Ilias)]

Yukihiro Matsumoto wrote:

=begin
I am sorry but I don't understand what you mean by this issue.

Nothing more than to provide a document, where some terminology which is used within the project is written down.

Note that (as always) this issue addresses the project, and not you individually.

Both global status and local status has String.call_initialize in examples.

"Global Status" was just an example (for inclusion into this document).

Contradicting proposals should be rejected, until the OP make it clear.

What is this now? An "issue-processing-rule"?

If you need further feed-back, clarification, just ask.

There is the "Feedback" status for this, no need to reject. I start to think that you invent new rules, just to be able to reject issues that I file immediately.

As to the "contradiction": There is no contradiction, I just demonstrate that there are different internal implementations of the same exposed api, which have influence on the scope of the status/state. Based on you definition, everything is "global status" and "maybe has problems with threads". But this is not the case. It's different if you have a global variable, a translation-unit bound variable, or and class-object-variable to carry the status.

By the way, any behavior of String class is global status. I don't prohibit global status. But adding new ((modifiable)) global status should be done carefully.

It is one thing to design carefully, it is another thing to reject with paranoia, or with unequal assessments. That's what test-cases/suites are for: to avoid paranoia, words and bias.

In addition, you state "thread introduces its own String class", but that's not how classes works in the language.

• I am aware that classes are global
• And I am aware that even the usage of a global $call_initialize would not have introduced any problems with threading.

It was you that mentioned "possible problems with threads".

So, I answered with an an hypothetical assumption, a phantasy's-worst-case scenario:

• "even if a user would somehow (e.g. using his creativity) introduce an own String class object for a thread. the code would still not break".

(as you know, people do not use the language as you intended them to do).

You have to understand the semantics of the language

The language is "peanuts", nothing special to understand. The only real difficulties are the inconsistencies (like the one I deal with in #4893).

before forcing us to adapt your understanding and expectation of the language-should-be,

This is complete nonsense, I cannot and I do not force anything, especially not "language-should-be".

before making proposals.

I've made here a very general proposal: the project should provide a document, in which terminology is defined.

This here would be the first addition to the document:

Yukihiro Matsumoto wrote: (within #4893)

Class objects can be accessed from everywhere. A modifiable attribute
of a globally accessible object is global status, in my terminology.

Anyone could then make a research to see if the terminology is correct, thus it can be updated.

Even if you insist to use non-standard terminology, it should be mentioned in the document.

And whenever there are problems with terminology, the document is extended with other terms.

[lazaridis.com (Lazaridis Ilias)]

=begin
Lazaridis Ilias wrote:

=begin

In order to avoid communication barriers, a document containing basic terminology should be provided (ideally directly within the source-code tree).
[...]

I've created a draft version of the document, this should clarify this issue:

((URL:http://redmine.ruby-lang.org/projects/ruby/wiki/Terminology))
=end