Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming of Array support functions (remaining: IsArrayBegin IsArrayEnd) #9

Closed
GoogleCodeExporter opened this issue Aug 25, 2015 · 5 comments

Comments

@GoogleCodeExporter
Copy link

Revision 90 (r90) is a version of a patch by Tim Blechmann to support 
SuperCollider arrays.

https://code.google.com/p/oscpack/source/detail?r=90

I have already tweaked the naming of symbols and functions relative to Tim's 
version. 

* The sentinel variables used to begin and end streaming an array have been 
renamed BeginArray and EndArray to harmonise with BeginMessage etc. Usage: 

ps << BeginMessage("/msg") << BeginArray << 1 << 2 << 3 << EndArray << 
EndMessage;

* The function to count the number of elements in the array is called 
ArrayItemCount(), this is consistent with ReceivedBundle::ElementCount(). I am 
not particularly fond of the fact that ArrayItemCount is O(n). Maybe it would 
be better to name it ComputeArrayItemCount().

* The tag constants are called ARRAY_START_TYPE_TAG and ARRAY_END_TYPE_TAG, 
perhaps ARRAY_START_TYPE_TAG should be called ARRAY_BEGIN_TYPE_TAG (another 
option is ARRAY_OPEN_TYPE_TAG and ARRAY_CLOSE_TYPE_TAG)

* We currently have IsArrayStart() and IsArrayEnd()

I'm not very convinced about having ~Start~ and ~Begin~. The meanings and usage 
are slightly different but I would prefer more consistency.

Also note that the other Is* functions in this context concern argument values 
but array begin and end are not values.

Another option:

ARRAY_BEGIN_MARKER_TYPE_TAG 
ARRAY_END_MARKER_TYPE_TAG
IsArrayBeginMarker()
IsArrayEndMarker()

Usually I would try to lift terminology from the OSC spec but I don't think it 
mentions arrays.

Thoughts?

Original issue reported on code.google.com by ross.bencina on 4 Mar 2013 at 9:01

@GoogleCodeExporter
Copy link
Author

naming: the osc1.0 specs talk about `begin` and `end` (array boundaries are 
optional type tags). so it would be reasonable to use that. adding `Marker` ... 
not sure if it increases the expressive power of the API, but i'm not a native 
speaker

computing element count: probably a good idea to add `Compute' to the name.

Original comment by tim.klin...@gmail.com on 4 Mar 2013 at 9:59

@GoogleCodeExporter
Copy link
Author

I've updated SVN as follows:
ARRAY_BEGIN_TYPE_TAG, ARRAY_END_TYPE_TAG
IsArrayBegin(), IsArrayEnd()
ComputeArrayItemCount()

As a native speaker I'm not entirely happy with IsArrayBegin/End but it's an 
improvement. I'm going to sleep on it.

Original comment by ross.bencina on 4 Mar 2013 at 10:23

@GoogleCodeExporter
Copy link
Author

I'm still struggling :

For now we have IsArrayBegin, IsArrayEnd for now. These have the advantage of 
starting with IsArray...  and ArrayBegin seems more like a noun for Is than 
BeginArray.

Some alternatives:

IsBeginArray -- Pro: BeginArray used elsewhere, Con: doesn't start with Array
IsBeginningOfArray -- Pro: reads well, in line with wording of spec, Con: 
semantics unclear (it's a pseudo argument that marks the beginning of an array, 
not actually the beginning of an array)
IsBeginningOfArrayTag -- ambiguous
IsBeginArrayMarker -- OK
IsBeginArrayTag -- OK but we don't use Tag anywhere else but it's a type tag

Original comment by ross.bencina on 6 Mar 2013 at 7:16

@GoogleCodeExporter
Copy link
Author

Original comment by ross.bencina on 6 Mar 2013 at 7:17

  • Changed title: Naming of Array support functions (remaining: IsArrayBegin IsArrayEnd)

@GoogleCodeExporter
Copy link
Author

Closing. What we have is good enough.

Original comment by ross.bencina on 26 Mar 2013 at 9:37

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant