collections and iterating? RRS feed

  • General discussion

  • First, I would like to say that this is an awesome project. I mean, I see this as a learning tool future generations of aspiring coders. But I do wonder why you can't declare variables as lists such as i = {1,2,3,4,5,6,7}, can't iterate through them foreach(j in i), and cant modify them i.add(), i.set(), i.remove()
    Even Dartmouth BASIC would let you dim your arrays. If not, what's the justification?

    Tuesday, June 22, 2010 5:00 AM

All replies

  • You can try this sample :

    Variable1["Test1"] = "1"
    Variable1["Test2"] = "2"
    Variable1["Test3"] = "3"
    AllIndices = Array.GetAllIndices(Variable1)
    it = Array.GetItemCount(Variable1)
    i = 1
    For i = 1 To it
    Variable1["Test3"] = ""

    Sorry My Bad English
    Tuesday, June 22, 2010 7:59 AM
  • This works... but it is neither simple or intuitive.
    Tuesday, June 22, 2010 6:06 PM
  • Hey there!

    Actually, you can declare variables as "lists". In general, Small Basic stores arrays as variables of the Primitive type. So declaring an array like this:

    Array1["Test1"] = 1
    Array1["Test2"] = 2
    Array1["Test3"] = 3

    is the same as writing it like this:

    Array1 = "Test1=1;Test2=2;Test3=3"

    I beleive the reason they set arrays up this way (someone correct me if I'm wrong) is because all objects provided by an extension can only receive parameters of the type Primitive. Therefore if you want to pass arrays as parameters, they must be of a Primitive type as well.

    You can also create arrays using the Array object, but the mechanism to get and put data is not straightforward. The arrays themselves are stored in the Array object so they cannot be directly referenced by your program.  The benefit to this method I've found is that there is a generous speed increase when working with large amounts of data. It will also allow you to remove specific indexes. Creating and modifiying the array looks something like this:

    'Initialize the array
    Array.setValue("ArrayName", "Index1", "Value1")
    Array.setValue("ArrayName", "Index2", "Value2")
    Array.setValue("ArrayName", "Index3", "Value3")
    'get a value from the array
    Value = Array.getValue("ArrayName", "Index1")
    'remove a value in the array
    Array.removeValue("ArrayName", "Index1")

    Of course, you can replace Index1, Index2, Index3 with 1, 2, 3 to more easily iterate through the list.

    Hope that helps! 

    Monday, June 28, 2010 9:32 PM
  • "The arrays themselves are stored in the Array object so they cannot be directly referenced by your program."

    If there is a speed increase in using the Array object then why does sb then not use the very same object internally to handle Arrays, globally of course. Then the current method of assinging Array values (Array["Index"] = Value) would just be a shorthand to the Array object. The Array object would then "reside in" sb itself. Arrays are a true weak spot for Microsoft Small Basic.


    Tuesday, June 29, 2010 1:53 PM
  • I understand your feelings about the arrays in Small Basic. I share some of that myself. Certainly the 2 array mechanisms in Small Basic lack some of the sophistication of more savvy languages, but you gotta cut it some slack, man! ;) It is only a teaching language after all. It wasn't exactly meant to handle processing Gigs of data. I would imagine such data handling is a little beyond its scope.

    As far as why they didn't allow the Array object to be referenced in the manner you describe (Array["Index"] = Value), I can think of 2 reasons:

    1. The Array object can hold more than 1 array. The method you describe only allows the Array object to handle 1 set of data.

    2. The Array object is not of the Primitive type. This could cause some confusion if you try to pass it as a parameter to an object like other arrays that are of the Primitive type.

    Course you would have to ask the creator of SB why he did it the way he did to get the real answers. I'm sure he could come up with many more valid reasons. None of them completely to our liking, as we would like to have things our way! ;) Ah well, that's life! I suppose we could always create an extension of our own to handle arrays.

    Wednesday, June 30, 2010 4:02 AM
  • From the bug thread:

    "One more thing.

    "And how about GraphicsWindow.Write and GraphicsWindow.WriteLine"

    This seems to conflict with the design for GraphicsWindow for if kids are going to be working with graphics then they better get used to how graphics actually work and that is true but this would provide consistency and avoid confusion and then the more advanged technical minded students could experiment with DrawText and this could be taken out with a teacher's option. Could have custom fonts with GraphicsWindow.Write and GraphicsWindow.WriteLine plus pixel position and clipping. If used well this approach could also be used to introduce OOP and pehaps inheritance, I leave it up to you guys to figure out how."

    Well, this is indeed a teaching language and I do not expect many of the things I suggested ever making it into the language but this is such a wonderful oppertunity and no need to dumb things to much down. With my first answer in this thread coupled with the answer from the bug thread then I envision two options, one to take the GraphicsWindow.Write thing away and another option that allows the functionality to remain in place to built custom commands into the language itself and those utilize OOP and a little bit of inheritance maybe.

    But hey, maybe in version 3.0 and then it will maybe have morphed into 'Microsoft Learning Studio" :)



    Wednesday, June 30, 2010 9:09 AM
  • Or instead of pure custom commands then you could have an objects editor and then the extensions provide functionality to the outside WIN32 API, or perhaps we could have both.
    Wednesday, June 30, 2010 9:30 AM
  • Uh, don't think the GraphicsWindow object has a Write or Writeline method.. Do you mean TextWindow? Did I miss something?
    Thursday, July 1, 2010 3:44 AM