Non-zero based array indexes

[DelphiGuy]

Charles:

I'm really struggling with a number of OOP/.Net issues, and particularly (at the moment) trying to understand abstract methods and interfaces. I've got no shortage of educational available, with C# apparently one of the most popular languages on the planet, but somehow the two books I have and the zillion articles online aren't synching with my psyche properly. I don't know why, exactly. I'd hate to learn Cobra by writing C# code (since I don't know anything about C#, either) along with a C# tutorial book, but it may be becoming necessary. Maybe I'll go over to Barnes and Noble and read the C# books there.

Yes, of course I've already read your custom list code but there's a good bit of it that's over my head, so I figured I'd start by trying to get something to compile, and then head into deeper waters, which I'm now doing.

Very little of my confusion at the moment is specifically about Cobra -- it's really OOP/.Net stuff.

One tangible thing that I think would help a little is being able to step through code with a debugger and see what's happening to the values. Since we don't have MD working as an integrated debugger under Win yet, can someone perhaps recommend the simplest (or highest level) tool for a beginner to use to debug Win? I've looked at the discussions pointed to by our Wiki, but it's going to take a bit to get it working, since I don't even know what to expect (I'm used to a completely ergonomic hand-holding high-level integrated debugger in Delphi).

Any comments whether it's going to be easiest to tackle the debugging in MonoDevelop (is this even possible considering that it won't cooperate with an integrated debug under Win) , SharpDevelop, or VS 2010 Express? Or something else?

Hey, I've done enough programming to know that as long as one is tenacious and keeps banging head against concepts, one will eventually become somewhat fluent in a language, but because there's so many new concepts, and I'm learning in a different lang than I'm wanting to write in, it's a bit of a challenge.

-P

[Charles]

Delphi also has abstract methods. Maybe that helps?

Maybe it's okay to learn C# too. There are tons on online resources. Search for things like "how to declare a generic class in C#". You can also try Visual Basic or "VB.NET".

Re: looking at values, the "trace" statement will give you the value, the source code of the expression and it's location:

Code: Select all

for i in 10
    trace i


Re: debugging, I don't have anything to add that is not on the wiki.

[hopscc]

I'll have a go :

Perhaps some of your difficulty getting a handle on these (interfaces vs abstract methods) is that a comparison of these two concepts is a comparison of items at two different levels of abstraction/detail - more directly comparable would be
interfaces vs abstract (base) classes
or
abstract method and an interface method.

I suspect that without a reasonable handle on these, looking at debugger output will be of little help since this is examining the output of concrete implementations ( the what - the above two are more a why (use these at all)).
However the wiki entry for debuggingsansVisualStudio suggests a commandline debugger (mdbg) that works with cobra/C#.

Another good source would be a google for 'interfaces' (includes wikipedia entries, Java and C#).
Skimming over these may give you something that strikes up a resonance...

Heres a rough take as a start point.

An interface is a specification or description for desired or expected behaviour.
It's used (called or implemented) as a simplification (conceptwise) and to give a general form of access to common behaviour across a number of concrete specific implementations.
The idea is that it provides a behaviour (or essence perhaps) with no inkling detail of how that behaviour is provided..

wrt .Net see ICollection - a simple high level description of the salient features of a Collection of items
( for a different though similar take for the same idea see Java java,util.Collection (interface))
salient items here are that a collection has a count of items and a way ( of obtaining a object ) allowing stepping/obtaining through the items in the(I)Collection.

The direct opposite ( and counterpart ) of an interface is an implementation.
Usually provided as a (concrete) class and used via an instance of that class.
This is all detail and all implementation though it advertises that it conforms to an interface (or multiple of them) so that rather ( or as well as) accessing the class directly you can access it through its interface ( like a simplification/commonality filter).

The benefit of these two is that they simplify use of a common concept (embodied in the interface) via a defined set of access points ( an interface surface). which eases understanding (reading calls) and allows simple substitution without massive code changes to the details of the publicly accessible points of an implementation.
Examples conforming to the above are .Net ArrayList (which as well as being an ICollection is also an IList) and a java java.util.Vector.

Hidden behind these concrete classes are details that may be necessary for behaviour but are irrelevant for use (coding wise)
(e.g Vector is synchronised(threadsafe) - java also has an ArrayList but it is not synchronised).
If you program to an interface/interfaces rather than to
implementations (concrete classes) its reasonably easy to change an implementation being used by just changing what is initially created/initialised
? Dont need synchronisation - just change initialisation to an ArrayList, the remainder of the code access is unchanged
Need some other behaviour ?
change initialisation to an implementation that provides that (underlying) behaviour that also conforms to the interface
So now your code is more robust in the face of possible change.
Arguably its also more understandable.

Advertising aside
interface -> behaviour only (what I want) - no implementation.
class -> implementation (how I'm gonna provide it) providing/supporting an (advertised) interface


Midway between the two is an abstract class ( or more usually an abstract base class) usually for providing some of the implementation of an interface ( also commonly a family or hierarchy of classes).

An abstract base class is a class that needs extending (or filling out) to provide a complete implementation but
as it is it provides some/many/much of the common parts of an implementation.
It's a template or skeleton providing some common behaviour (across all implementations/subclasses that use it) and
otherwise unable to stand alone ( i.e it exists only to be subclassed).
The bits that need the concrete implementations created (methods usually) are marked abstract -
expecting that this abstract class will be subclassed and the pieces marked 'abstract' will be filled in (implemented concretely) in the subclass.

An abstract method is an incomplete implementation ( a placeholder) for a method that needs to be completed to provide the full implementation of that method ( and perhaps in the context of this discussion) also the implementation of a method for an interface where the abstract Base class advertises as implementing the interface.
examples here .Net CollectionsBaseClass and Java java.util.AbstractCollection

Hope the above helps some. I've thrown a lot of similar words concepts in here around these 3 things in the hope that some/one of them strikes up something that makes sense with what you've encountered before..

[DelphiGuy]

hopscc:

Thanks for the thoughtful and lengthy discussion of these programming concepts. I've printed it out and will read it until I understand it. In the interim I've decided that I am not going to be able to "wing it" by learning Cobra/.NET/OOP concepts as I need them.

So I've gone back to the very beginning to learn Cobra, starting from square one, from Troelsen's "Pro C# 2008 and the .NET 3.5 Platform", published by Apress. I happen to already own, so I'm not currently buying the newer editions.

I'm reading it, pretty much from the beginning, and working through at least some of each example given, but instead of writing in C# I'm converting the "homework" examples into Cobra as I go. So far, so good, and I imagine I'll end up a half-decent Cobra/.NET programmer by going back and getting a complete foundation, from the beginning, in a systematic way this time.

I'll keep you guys posted on my progress, if for no other reason than I'll probably have questions as I go along.

Thanks again for all of your patience and support. I love Cobra and still intend to make it my main lang, and still intend to eventually use it for a MonoTouch MIDI project.

Regarding the question of a debugger, rumor has it that nerdzero has made a triumphant initial success of getting the MonoDevelop debugger to work under Win, and is planning to provide instructions within the next week or so. So that will become my integrated Cobra development environment.

-Paul

[nerdzero]

Regarding the question of a debugger, rumor has it that nerdzero has made a triumphant initial success of getting the MonoDevelop debugger to work under Win, and is planning to provide instructions within the next week or so

Yep! I got it to work but you have to install Cobra targeting the x86 platform and some other goofy stuff. This is due to some issues with loading some of the 32-bit assemblies used by MonoDevelop using System.Reflection. Full instructions coming soon hopefully. Getting all my ducks in a row...