Skill ++ and DataStructures

[Sa]

Hello all,
1. I havnt seen anybody atleast in my company using SKILL++. May I
know whats the problem with it?( I like Object oriented programming)
2. ~> is supposed to work in similar way as that of -> ( according to
documenation) but I tried using ~> on a list of disembodied property
list items, it doesnt work. Why?? is it a bug?
3. I am writing an application where I have to deal with several
thousands of records...what data structure I should use?
is it better to use tables with different keys?? like
tbl["prop1"]
tbl["prop2"]
(If I am processing list of such tbls I cant use ~>. I have to go
each and every element in list and do tbl["prop1"])
or should I use dissembodied property lists
tbl = ncons(nil)
tbl->prop1 = ...
tbl->prop2 = ...
( I cant use ~> to get prop1 from list of "tbl"s)
or shld I use defstructs??
( pain to make these defstructs..)


Please give me some sugestions.
Thanks
Sampath

 

[Pete nospam Zakel]

In article <1351722e.0401191655.fd3c373@posting.google.com> sampath_dechu@rediffmail.com (Sa) writes:

2. ~> is supposed to work in similar way as that of -> ( according to
documenation) but I tried using ~> on a list of disembodied property
list items, it doesnt work. Why?? is it a bug?

-> and ~> work differently:

myDpl = list( nil 'prop1 "valueOfProp1" )
(nil prop1 "valueOfProp1")
putprop( 'myDpl "prop1Value" 'prop1 )
"prop1Value"
myDpl->prop1
"valueOfProp1"
myDpl~>prop1
*Error* get/getq: first arg must be either symbol, list, defstruct or user

type - "valueOfProp1"

get( myDpl 'prop1 )
"valueOfProp1"
get( 'myDpl 'prop1 )
"prop1Value"
getq( 'myDpl prop1 )
"prop1Value"
getq( myDpl prop1 )
"valueOfProp1"
getqq( myDpl prop1 )
"prop1Value"
myVar = 'myDpl
myDpl
myVar~>prop1
"prop1Value"
eval(myVar)->prop1
"valueOfProp1"
myDpl->prop1
"valueOfProp1"
myVar->prop1
"prop1Value"

So the evaluation of the left-hand-side of -> and ~> are slightly different.

-Pete Zakel
(phz@seeheader.nospam)

"Sometimes a cigar is just a cigar."
-Sigmund Freud

 

[Pete nospam Zakel]

I think I figured it out.

x->y evals x and then invokes getq( eval_of_x y )

and

x~>y evals x and then invokes getqq( eval_of_x y )

-Pete Z.

In article <400c8ddb$1@news.cadence.com> pxhxz@cadence.com (Pete nospam Zakel) writes:

In article <1351722e.0401191655.fd3c373@posting.google.com> sampath_dechu@rediffmail.com (Sa) writes:

2. ~> is supposed to work in similar way as that of -> ( according to
documenation) but I tried using ~> on a list of disembodied property
list items, it doesnt work. Why?? is it a bug?

-> and ~> work differently:

myDpl = list( nil 'prop1 "valueOfProp1" )
(nil prop1 "valueOfProp1")
putprop( 'myDpl "prop1Value" 'prop1 )
"prop1Value"
myDpl->prop1
"valueOfProp1"
myDpl~>prop1
*Error* get/getq: first arg must be either symbol, list, defstruct or user
type - "valueOfProp1"
get( myDpl 'prop1 )
"valueOfProp1"
get( 'myDpl 'prop1 )
"prop1Value"
getq( 'myDpl prop1 )
"prop1Value"
getq( myDpl prop1 )
"valueOfProp1"
getqq( myDpl prop1 )
"prop1Value"
myVar = 'myDpl
myDpl
myVar~>prop1
"prop1Value"
eval(myVar)->prop1
"valueOfProp1"
myDpl->prop1
"valueOfProp1"
myVar->prop1
"prop1Value"

So the evaluation of the left-hand-side of -> and ~> are slightly different.

-Pete Zakel
(phz@seeheader.nospam)

"Sometimes a cigar is just a cigar."
-Sigmund Freud

 

[Andrew Beckett]

On 19 Jan 2004 16:55:33 -0800, sampath_dechu@rediffmail.com (Sa) wrote:

Hello all,
1. I havnt seen anybody atleast in my company using SKILL++. May I
know whats the problem with it?( I like Object oriented programming)

There is no problem with it. Not sure why you think there is. It's not that
commonly used because many of the advantages of it are only apparent
with larger applications, and a lot of SKILL code is for small applications.

2. ~> is supposed to work in similar way as that of -> ( according to
documenation) but I tried using ~> on a list of disembodied property
list items, it doesnt work. Why?? is it a bug?

No, it's not a bug. ~> is a way of retrieving the value of an attribute or
property
on an object, as is ->. However, they way that they work with lists
is different (and this indeed is the difference).

If I have a database object, and do:

dbObj~>objType
dbObj->objType

then they return the same thing.

If I have a list of objects:

objs=cellView~>shapes

then if I do:

objs~>objType

it returns a list of the objType attribute values for each shape in turn. In
other words, if the left hand side of the ~> is a list, it implicitly does:

foreach(mapcar obj objs obj~>objType)

Since a disembodied property list is a list, if you use ~> on it, it would try
to do ~> on each entry in that list and return the values accordingly. That's
not what you want, so you have to use the -> operation instead. Similarly, if
the left hand side of -> is a list, it assumes it's a DPL.

3. I am writing an application where I have to deal with several
thousands of records...what data structure I should use?
is it better to use tables with different keys?? like
tbl["prop1"]
tbl["prop2"]
(If I am processing list of such tbls I cant use ~>. I have to go
each and every element in list and do tbl["prop1"])
or should I use dissembodied property lists
tbl = ncons(nil)
tbl->prop1 = ...
tbl->prop2 = ...
( I cant use ~> to get prop1 from list of "tbl"s)
or shld I use defstructs??
( pain to make these defstructs..)

Using disembodied property lists is probably not a good idea. I don't see
why making defstructs is a problem, since you only have to do it once
for each structure type (if you like objected oriented programming, you ought to
be used to doing this?).

Using a table is probably overkill unless you have a large number of
keys or properties on the object which differ each time.

To be honest I can't give recommendations about the best structure
to use without knowing more about the application. There are a range
of different structures in SKILL because some are good for somethings,
and some are good for others.

Best Regards,

Andrew.

Please give me some sugestions.
Thanks
Sampath

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd