Array of Unbounded_String vs Indefinite_Vectors(Natural, String)

Array of Unbounded_String vs Indefinite_Vectors(Natural, String)

[Victor Porton]

I need to develop an API which return a list of strings.

I have two possible design choices for the result type:

1. type T is array(Natural range <>) of Unbounded_String;

2. package V is new Ada.Containers.Indefinite_Vectors(Natural, String);

Which one of the two to choose?

The first has the advantage that it is a regular array not a fancy 
container. The second one has the advantage that the element type is String 
not a fancy Unbounded_String.

Please help me to make the choice!

-- 
Victor Porton - http://portonvictor.org

Re: Array of Unbounded_String vs Indefinite_Vectors(Natural, String)

[Shark8]

On Saturday, October 21, 2017 at 3:48:48 PM UTC-6, Victor Porton wrote:
> I need to develop an API which return a list of strings.
> 
> I have two possible design choices for the result type:
> 
> 1. type T is array(Natural range <>) of Unbounded_String;
> 
> 2. package V is new Ada.Containers.Indefinite_Vectors(Natural, String);
> 
> Which one of the two to choose?
> 
> The first has the advantage that it is a regular array not a fancy 
> container. The second one has the advantage that the element type is String 
> not a fancy Unbounded_String.
> 
> Please help me to make the choice!

Personally I like the vector option.
There's a third choice, an array of unconstrained Holder container -- http://www.ada-auth.org/standards/12rat/html/Rat12-8-5.html -- You could overload your array-type with an operator to directly return the string.

Assuming you've instantiated String_Holder, you could do something like this.

Type String_List is Array(Positive range <>) of String_Holder.Holder;
Function "/"( List : String_List; Index : Positive ) return String is
( String_Holder.Element( List(Index) ) )
with Pre => Index in List'Range;

Re: Array of Unbounded_String vs Indefinite_Vectors(Natural, String)

[Victor Porton]

Shark8 wrote:

> On Saturday, October 21, 2017 at 3:48:48 PM UTC-6, Victor Porton wrote:
>> I need to develop an API which return a list of strings.
>> 
>> I have two possible design choices for the result type:
>> 
>> 1. type T is array(Natural range <>) of Unbounded_String;
>> 
>> 2. package V is new Ada.Containers.Indefinite_Vectors(Natural, String);
>> 
>> Which one of the two to choose?
>> 
>> The first has the advantage that it is a regular array not a fancy
>> container. The second one has the advantage that the element type is
>> String not a fancy Unbounded_String.
>> 
>> Please help me to make the choice!
> 
> Personally I like the vector option.

Why?

-- 
Victor Porton - http://portonvictor.org

Re: Array of Unbounded_String vs Indefinite_Vectors(Natural, String)

[Victor Porton]

Victor Porton wrote:

> I need to develop an API which return a list of strings.
> 
> I have two possible design choices for the result type:
> 
> 1. type T is array(Natural range <>) of Unbounded_String;
> 
> 2. package V is new Ada.Containers.Indefinite_Vectors(Natural, String);
> 
> Which one of the two to choose?
> 
> The first has the advantage that it is a regular array not a fancy
> container. The second one has the advantage that the element type is
> String not a fancy Unbounded_String.
> 
> Please help me to make the choice!

"2" is preferred, because it is more flexible: String can be replaced with 
some another type without big code changes.

-- 
Victor Porton - http://portonvictor.org

Re: Array of Unbounded_String vs Indefinite_Vectors(Natural, String)

[Shark8]

On Sunday, October 22, 2017 at 4:52:56 AM UTC-6, Victor Porton wrote:
> Shark8 wrote:
> > 
> > Personally I like the vector option.
> 
> Why?

Because I've found it to be the most natural solution to the problem when I've had to do something similar. Though, to be fair, I /was/ storing constant words (commands [or tokens]) rather than mutable strings that could change length.

As always, consider the problem domain *first* before jumping into code -- this helps prevent you from falling into the "I have a hammer, so everything is a nail" mentality -- Ada is really quite good at modeling the problem domain for a lot of things, and we should take advantage of that.

Re: Array of Unbounded_String vs Indefinite_Vectors(Natural, String)

[Jacob Sparre Andersen]

Shark8 wrote:

> Because I've found it to be the most natural solution to the problem
> when I've had to do something similar. Though, to be fair, I /was/
> storing constant words (commands [or tokens]) rather than mutable
> strings that could change length.

Good point.

If you're planning to change the strings after they have been inserted,
that may be an argument in favour of using Unbounded_String (and thus
allowing a "plain" array for the data structure).

You might also consider if array/vector is the right kind of data
structure.  Are you sure it isn't a list or a set?

Greetings,

Jacob
-- 
The so-called "desktop metaphor" of today's workstation
is instead an "airplane-seat" metaphor.

Re: Array of Unbounded_String vs Indefinite_Vectors(Natural, String)

[Robert Eachus]

On Monday, October 23, 2017 at 12:32:09 PM UTC-4, Shark8 wrote:
 
> As always, consider the problem domain *first* before jumping into code -- this helps prevent you from falling into the "I have a hammer, so everything is a nail" mentality -- Ada is really quite good at modeling the problem domain for a lot of things, and we should take advantage of that.

In the early days of Ada--when working on a compiler before there were any validated compilers, I said to one of my co-workers: "No! In Ada always model the problem domain. not the solution domain."  I then went and wrote it on my whiteboard.  It really is one of the fundamentals of Ada, if not the fundamental rule.  If your model is fitted to a description of the problem domain, changes in the requirements won't change the world you are modelling.  In addition, you may/will be able to reuse more of your code to solve other problems in the same domain.

Just to make it clear, a component package might require say a hash table.  That's fine, but if you look at how the Ada components are organized, you can later replace it with a multi-way tree with very little effort.  In this case the problem space is some things to be organized, and the hash table is a solution.