After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 156633 - [API] don't use same API for arrays as for normal lists
[API] don't use same API for arrays as for normal lists
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal normal
: 0.9.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 319388
 
 
Reported: 2004-10-27 20:05 UTC by Benjamin Otte (Company)
Modified: 2005-11-19 16:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Benjamin Otte (Company) 2004-10-27 20:05:04 UTC
Please describe the problem:
GST_TYPE_FIXED_LIST should be named GST_TYPE_ARRAY.
There should also be seperate functions to access arrays and lists in the API.

It would IMO also be nice if arrays would use [] instead of <> when they're
converted to strings.

Steps to reproduce:



Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Benjamin Otte (Company) 2004-10-27 20:05:51 UTC
I should have put that in "Other information":
The simple bug assistant is cool :)
Comment 2 David Schleef 2004-10-27 23:51:33 UTC
What character do you propose to use for ranges, then?
Comment 3 Benjamin Otte (Company) 2004-10-28 07:55:46 UTC
I'm not sure. The problem is that we're using a C-like notation for caps right
now. In C an array is defined like this:
type array[] = { val1, val2, ... }
That definition has 2 different bracket types, but no < > brackets, so it looks
a bit unnatural.
In this context it's worth thinking about what syntax C-like notations use for
lists and ranges. Ranges are mostly identified via dots in some languages (for
example the GNU extension for switch statements. I'm not sure how nice
"value=(double) 1.234 ... 2.345" looks though. And this notation is missing a
simple identifier for the parser that it's indeed a range and not just
"value=(double) 1.234"
Comment 4 Ronald Bultje 2005-04-14 17:10:07 UTC
In 0.9, the {} are free because explicit threads are gone. We can use {}. Anyone
wanna patch up 0.9 now?
Comment 5 Benjamin Otte (Company) 2005-04-19 10:10:23 UTC
caps notation != pipeline notation

:)
Comment 6 Benjamin Otte (Company) 2005-06-06 14:54:36 UTC
The API for arrays should also be different from lists to avoid confusion.
I recently committed a wrong "fix" because I didn't get why the same value was
added x times to a list.
Which was of course correct because it was an array, but that was not obvious
from the API used.

There's also lots of special case ifs only executed for (non)fixed lists in the
accessor functions.
Comment 7 Andy Wingo 2005-07-15 15:56:54 UTC
Targetting to 0.9.x, one way or another.
Comment 8 Ronald Bultje 2005-07-20 17:27:32 UTC
I renamed FixedList, I don't want to add extra API so leaving that for others to
fight about.
Comment 9 Andy Wingo 2005-11-14 10:31:57 UTC
I think the extra API would make things more clear. Also it would allow type
checking and unambiguous documentation. Adding to bug #319388...
Comment 10 Andy Wingo 2005-11-19 16:49:46 UTC
Fixed in CVS