[Year 12 SofDev] Records VS Classes
Chris Bucknell
Chris.Bucknell at haileybury.vic.edu.au
Fri Feb 26 15:15:42 AEDT 2016
Hi All,
I do love the discussions that vocabulary brings about. A record in computing has a variety of definitions:
· A collection of data items in a file or data set,
· A user defined type, being a concatenation of one or more members of various data types,
· A group of fields within a table in a database that are relevant to a specific entity,
· A unit of data that is transmitted from a sender to a receiver,
· (I’m sure there are other esoteric examples)
These definitions are used in different contexts and for different technologies, so that’s why IMHO I believe we need to consider the context that “record” was identified in (i.e types of data structures) and in that case we would be considering a user defined type (a single variable that records several related pieces of information).
Now the next important issue is how we implement it this in the multitude of programming languages that are available to us. Do we use a structure/struct, a class, or … (please insert your favour technology implementation here)? Do we need to consider stack and heap issues or the memory consumptions of the implementation of the data type? Once again IMHO we might be reading far too much into a single word (given the context it is used in). As highlighted previously, some programming languages do not directly support this concept, but importantly the “record” dot point is in the “key knowledge” so therefore do you need to directly implement it in code?
Just my 5 cents worth (I upped the thinking time on this one ☺)
Regards
Chris Bucknell
Head of CDT; Coord, Internal Exam; House Tutor
+61 3 9904 6360
Chris.Bucknell at haileybury.vic.edu.au<mailto:%7bemail%7d>
www.haileybury.vic.edu.au<http://www.haileybury.vic.edu.au>
From: sofdev-bounces at edulists.com.au [mailto:sofdev-bounces at edulists.com.au] On Behalf Of Guy Flaherty
Sent: Friday, 26 February 2016 1:34 PM
To: Year 12 Software Development Teachers' Mailing List
Subject: Re: [Year 12 SofDev] Records VS Classes
For those using Python it might be a little difficult to show a ‘record’ type, as there isn’t really one. The usual answer is to create a class and use it as a record type. In python, a class without methods only attributes is the common way to represent a struct or record type from other languages.
However, if you are using Python 3.3 or greater you can use the SimpleNamespace type from the types module which is pretty close to a record type and is built in. Otherwise you could look into namedtuples. For reference:
https://www.daniweb.com/programming/software-development/code/216597/class-implements-a-structurerecord-python
http://stackoverflow.com/questions/5227839/why-python-does-not-support-record-type-i-e-mutable-namedtuple
You might need to spend time comparing python’s lack of record types with other languages to get the idea across if your students are used to the python way of using variables. It would be difficult, for example, to limit a python object to a fixed number of attributes without creating a class to represent a record.
I am not sure if it would be accepted that a class and a record can be the same thing?
Guy Flaherty
From: sofdev-bounces at edulists.com.au<mailto:sofdev-bounces at edulists.com.au> [mailto:sofdev-bounces at edulists.com.au] On Behalf Of Chris Bucknell
Sent: Friday, 26 February 2016 12:15 PM
To: Year 12 Software Development Teachers' Mailing List <sofdev at edulists.com.au<mailto:sofdev at edulists.com.au>>
Subject: Re: [Year 12 SofDev] Records VS Classes
Hi Ben,
That is the way that I read it also. I think the context of the dot point containing the identification of records and its elaboration in brackets – varying data types, field index – means that it must be a user defined data structure (i.e structs – C, structures – VB or records – pascal)
So to expand (with thanks to Wikipedia https://en.wikipedia.org/wiki/Record_(computer_science) )
· A record is a collection of fields/elements, possibly of different data types, typically in fixed number and sequence.
· Records are distinguished from arrays by the fact that their number of fields is typically fixed, each field has a name, and that each field may have a different type.
Just my two cents worth.
Regards
Chris Bucknell
Head of CDT; Coord, Internal Exam; House Tutor
+61 3 9904 6360
Chris.Bucknell at haileybury.vic.edu.au<mailto:%7bemail%7d>
www.haileybury.vic.edu.au<http://www.haileybury.vic.edu.au>
From: sofdev-bounces at edulists.com.au<mailto:sofdev-bounces at edulists.com.au> [mailto:sofdev-bounces at edulists.com.au] On Behalf Of Baas, Benjamin B
Sent: Friday, 26 February 2016 7:53 AM
To: Year 12 Software Development Teachers' Mailing List
Subject: Re: [Year 12 SofDev] Records VS Classes
The study design mentions records under the dot point referring to data structures. To me that sounds like they want to us to look at records with in the programming language. In the case of the C languages and VB struts or structures. That’s my interpretation. I might ask Paula.
· types of data structures, including one-dimensional arrays (single data type, integer index) and records (varying data types, field index)
Cheers,
Ben.
From: sofdev-bounces at edulists.com.au<mailto:sofdev-bounces at edulists.com.au> [mailto:sofdev-bounces at edulists.com.au] On Behalf Of Paragreen, Chris J
Sent: Thursday, 25 February 2016 3:40 PM
To: Year 12 Software Development Teachers' Mailing List <sofdev at edulists.com.au<mailto:sofdev at edulists.com.au>>
Subject: Re: [Year 12 SofDev] Records VS Classes
My interpretation is that we need to teach records as in files and records, as opposed to the language specific data structure. How you then implement the record is up to … you? … the students? I’m also thinking that might tie into XML and the importing and exporting of data. Please tell me if my interpretation is wrong!
Chris
From: sofdev-bounces at edulists.com.au<mailto:sofdev-bounces at edulists.com.au> [mailto:sofdev-bounces at edulists.com.au] On Behalf Of Laurie Savage
Sent: Thursday, 25 February 2016 2:03 PM
To: Year 12 Software Development Teachers' Mailing List <sofdev at edulists.com.au<mailto:sofdev at edulists.com.au>>
Subject: Re: [Year 12 SofDev] Records VS Classes
Always a good idea to teach what is in the study design even if current practice is moving past it.
Laurie Savage
PVGC
Laurie Savage
https://sites.google.com/a/pvgc.vic.edu.au/mr-savage/home
On 25 February 2016 at 13:15, Baas, Benjamin B <baas.benjamin.b at edumail.vic.gov.au<mailto:baas.benjamin.b at edumail.vic.gov.au>> wrote:
Hi all,
I just wanted to get people’s opinions, as part of the study design we have to teach our students about record data structures. If we have to use an OO language would it not be best to just teach them how to make classes.
I haven’t done structs in C# before, only C, and to me it feels like I should just teach me students how to make basic classes and not worry about teaching sturcts. I will teach them structs as that’s what the study design says.
Cheers,
Ben.
Benjamin Baas
[Description: cid:image001.png at 01C9CA67.50F474D0] Alkira Secondary College
• Nurture Ave, Cranbourne North | PO Box 4314, Narre Warren South 3805
' +61 3 5991 3500<tel:%2B61%203%205991%203500> 6 +61 3 5991 3599<tel:%2B61%203%205991%203599> • www.alkirasecondarycollege.com.au<http://www.alkirasecondarycollege.com.au/>
Alkira Secondary College believes in Personalised learning for all, and Respect for the individual
IMPORTANT - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Training.
IMPORTANT - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Training.
IMPORTANT - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Training.
IMPORTANT - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Training.
________________________________
This email, including any attachments, is confidential. If you are not the intended recipient you must not copy, use, disclose, distribute or rely on this information. If you have received this email in error, please notify the sender immediately by reply email and delete the email from your system. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of mistaken delivery to you. Haileybury does not guarantee that this email is unaffected by computer virus, corruption or other defects. Haileybury monitors all incoming and outgoing email for compliance with its IT Policies. ABN: 34 004 228 906
________________________________
This email, including any attachments, is confidential. If you are not the intended recipient you must not copy, use, disclose, distribute or rely on this information. If you have received this email in error, please notify the sender immediately by reply email and delete the email from your system. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of mistaken delivery to you. Haileybury does not guarantee that this email is unaffected by computer virus, corruption or other defects. Haileybury monitors all incoming and outgoing email for compliance with its IT Policies. ABN: 34 004 228 906
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.edulists.com.au/pipermail/sofdev/attachments/20160226/841a017f/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2633 bytes
Desc: image001.png
Url : http://www.edulists.com.au/pipermail/sofdev/attachments/20160226/841a017f/image001-0001.png
More information about the sofdev
mailing list