On 03/06/2015 05:16, Eddilbert Macharia wrote:
On Tuesday, June 2, 2015 at 2:27:31 PM UTC+3, Steven D'Aprano wrote:

Eddilbert, have you programmed in any other languages? It would help you
understand if you have.

Sadly yes i have worked with java, and that is what is causing me so much 
grief.In java objects are instance of a class.pretty simple.

In Python 2:

- everything is an object [the general concept]

- some things, but not all things, are instances of the class
   called "object"


In Python 3:

- everything is an object [the general concept]

- everything is an instance of the class called "object"

I think then in python object and instance of a class are entirely different 
things.

in OOP and python - object is a representation of a real thing, or a concept 
.e.g a person,number and the concept of classes- which is the concept of 
create/representing other objects using a programming language to the machine.

class - This is what is used to create/represent objects in the machine using a 
programming language

class instance - This is the output of the classes this is a representation of 
an object.

I have a lot of trouble with this stuff too, as my ideas are decidedly old-fashioned. (Also I'm developing a language with some OO aspects without ever having used OO!)

But, it is mostly just jargon. If you go back to using 'variable' and 'type', then it becomes a bit easier:

* A variable is an instance of some type.

And, that's pretty much it!

However, modern languages such as Python add a few more twists. So, if a static, compiled language, say, had these kinds of things:

- Module
- Record definition
- Enum type
- Label (for goto)
- Function
- Type

which are normally entities that only the compiler are concerned with, then these can now also be values that can be stored in variables! (One or two such languages might allow pointers to Functions or Labels, but that's about it.)

Exactly what it is about a Module, Record or Function that is stored in the variable is an implementation detail. The important thing is that you can use such as variable at runtime in the same way you might do at compile-time.

Python of course would subsume concepts such as Records or Enums into a class, as it seems to like to unify what it considers to be untidy, separate aspects of a language. Some of us however need things separated out again in order to understand them!

(This is a set of codes I'm using in a current compiler project, for a new language. Each denotes a separate kind of identifier in the input source:

        nullid = 0
        programid = 1
        moduleid = 2
        extmoduleid = 3
        classid = 4
        procid = 5
        staticid = 6
        constid = 7
        fieldid = 8
        genfieldid = 9
        enumid = 10
        paramid = 11
        frameid = 12
        varid = 13      # ?
        labelid = 14
        blockid = 15
        attribid = 16
        aliasid = 17

The language requires that each identifier is resolved at compile-time to one of the above. This makes it rather less dynamic than Python, where the bytecode compiler, as far as I know, only resolves a name as either global or local (and perhaps attribute, but I'm not an expert on its workings).

(The 'varid' code was for a unresolved top-level name, which I will probably remove as that was added when I'd intended to emulate Python more. But that was too much work (and too many speed-ups were no longer trivial). Some codes such as 'nullid' and 'programid' are only used internally.

'genfield' is a field (attribute) that can't be resolved, but the possibilities have been reduced to a small, finite set which is resolved at load-time (in Python, the attribute could be anything, and you don't even know at runtime what it might be until you actually use the attribute.)

In this list, then 'static', 'frame', and 'param' denote what I'd call variables. A variable, at runtime, contains a value of a certain type (another list of codes). One of those types however is a Symbol: just a reference (a symbol table index) to a resolved name in the source code.

Just a different approach to things. But since the ultimate aim is to be able to write programs, not so different.)

--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to