Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-11-02T18:01:47Z

Varjun2:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big> <ref>http://www.youtube.com/watch?v=OG8i9Udqm_s</ref>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture for a post:

post_one:
title: one
description: post_one_desc
category: category_one

post_two:
title: two
description: post_two_desc
category: category_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category
one, post_one_desc, category_one
two, post_two_desc, category_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

The following example shows how a factory can be defined using Factory Girl:

Factory.define :post do |p|
p.title 'Fixtures and Factories'
p.description 'This a wiki for fixtures and factories'
p.category 'OOLS'
end

=Fixtures vs. Factories=

Fixtures allow known data to be statically pre-loaded into database tables before testing. Factories create only whatever is needed on a case by case basis.

==Fixtures Advantages==

* Easy to view all the data in one place
* Data is truly static
* Simple and clean

==Fixtures Disadvantages==

* Inserting data into the database for each run slows down the testing process
* Introduces dependency on fixture data
* Data customization is more complex
* Fixtures cannot be parameterized

==Factories Advantages==

* Maintains independence of tests
* Better overall performance since data is created only on a per need basis
* Tests and data are well isolated

==Factories Disadvantages==

* Complex relationships might be hard to capture
* Performance might sometimes be degraded, due to the create operations.

= Conclusion =

The article discusses how fixtures and factories are used with regard to testing. The different types of factories have been enumerated.The Factory Girl example is used to explain how factories are used. Different situations are explained where the use of fixtures and factories are contrasted. The advantages and disadvantages of both the approaches help throw some light on where the user must use fixtures and where the user must opt for factories.

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-11-02T17:53:22Z

Varjun2:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big> <ref>http://www.youtube.com/watch?v=OG8i9Udqm_s</ref>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture for a post:

post_one:
title: one
description: post_one_desc
category: category_one

post_two:
title: two
description: post_two_desc
category: category_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category
one, post_one_desc, category_one
two, post_two_desc, category_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

The following example shows how a factory can be defined using Factory Girl:

Factory.define :post do |p|
p.title 'Fixtures and Factories'
p.description 'This a wiki for fixtures and factories'
p.category 'OOLS'
end

=Fixtures vs. Factories=

Fixtures allow known data to be statically pre-loaded into database tables before testing. Factories create only whatever is needed on a case by case basis.

==Fixtures Advantages==

* Easy to view all the data in one place
* Data is truly static
* Simple and clean

==Fixtures Disadvantages==

* Inserting data into the database for each run slows down the testing process
* Introduces dependency on fixture data
* Data customization is more complex
* Fixtures cannot be parameterized

==Factories Advantages==

* Maintains independence of tests
* Better overall performance since data is created only on a per need basis
* Tests and data are well isolated

==Factories Disadvantages==

* Complex relationships might be hard to capture
* Performance might sometimes be degraded, due to the create operations.

= Conclusion =

The article discusses how fixtures and factories are used with regard to testing. The different types of factories have been enumerated.The Factory Girl example is used to explain how factories are used. Different situations are explained where the use of fixtures and factories are contrasted. The advantages and disadvantages of both the approaches help throw some light on where the user must use fixtures and where the user must opt for factories.

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-11-02T17:33:37Z

Varjun2:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big> <ref>http://www.youtube.com/watch?v=OG8i9Udqm_s</ref>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture for a post:

post_one:
title: one
description: post_one_desc
category: category_one

post_two:
title: two
description: post_two_desc
category: category_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category
one, post_one_desc, category_one
two, post_two_desc, category_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

The following example shows how a factory can be defined using Factory Girl:

Factory.define :post do |p|
p.title 'Fixtures and Factories'
p.description 'This a wiki for fixtures and factories'
p.category 'OOLS'
end

=Fixtures vs. Factories=

Fixtures allow known data to be statically pre-loaded into database tables before testing. Factories create only whatever is needed on a case by case basis.

==Fixtures Advantages==

* Easy to view all the data in one place
* Data is truly static
* Simple and clean

==Fixtures Disadvantages==

* Inserting data into the database for each run slows down the testing process
* Introduces dependency on fixture data
* Data customization is more complex
* Fixtures cannot be parameterized

==Factories Advantages==

* Maintains independence of tests
* Better overall performance since data is created only on a per need basis
* Tests and data are well isolated

==Factories Disadvantages==

* Complex relationships might be hard to capture
* Performance might sometimes be degraded, due to the create operations.

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-27T00:05:51Z

Varjun2:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture for a post:

post_one:
title: one
description: post_one_desc
category: category_one

post_two:
title: two
description: post_two_desc
category: category_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category
one, post_one_desc, category_one
two, post_two_desc, category_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

The following example shows how a factory can be defined using Factory Girl:

Factory.define :post do |p|
p.title 'Fixtures and Factories'
p.description 'This a wiki for fixtures and factories'
p.category 'OOLS'
end

=Fixtures vs. Factories=

Fixtures allow known data to be statically pre-loaded into database tables before testing. Factories create only whatever is needed on a case by case basis.

==Fixtures Advantages==

* Easy to view all the data in one place
* Data is truly static
* Simple and clean

==Fixtures Disadvantages==

* Inserting data into the database for each run slows down the testing process
* Introduces dependency on fixture data
* Data customization is more complex
* Fixtures cannot be parameterized

==Factories Advantages==

* Maintains independence of tests
* Better overall performance since data is created only on a per need basis
* Tests and data are well isolated

==Factories Disadvantages==

* Complex relationships might be hard to capture
* Performance might sometimes be degraded, due to the create operations.

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-27T00:05:06Z

Varjun2:

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-26T23:57:49Z

Varjun2:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture for a post:

post_one:
title: one
description: post_one_desc
category: category_one

post_two:
title: two
description: post_two_desc
category: category_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category
one, post_one_desc, category_one
two, post_two_desc, category_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

The following example shows how a factory can be defined using Factory Girl:

Factory.define :post do |p|
p.title 'Fixtures and Factories'
p.description 'This a wiki for fixtures and factories'
p.category 'OOLS'
end

=Fixtures vs. Factories=

Fixtures allow known data to be statically pre-loaded into database tables before testing. Factories create only whatever is needed on a case by case basis.

==Fixtures Advantages==

* Easy to view all the data in one place
* Data is truly static
* Simple and clean

==Fixtures Disadvantages==

* Inserting data into the database for each run slows down the testing process
* Introduces dependency on fixture data
* Data customization is more complex
* Fixtures cannot be parameterized

==Factories Advantages==

* Maintains independence of tests
* Better performance since data is created only on a per need basis
* Tests and data are well isolated

==Factories Disadvantages==

* Complex relationships might be hard to capture
*

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-26T23:42:26Z

Varjun2:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture for a post:

post_one:
title: one
description: post_one_desc
category: category_one

post_two:
title: two
description: post_two_desc
category: category_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category
one, post_one_desc, category_one
two, post_two_desc, category_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

The following example shows how a factory can be defined using Factory Girl:

Factory.define :post do |p|
p.title 'Fixtures and Factories'
p.description 'This a wiki for fixtures and factories'
p.category 'OOLS'
end

=Fixtures vs. Factories=

Fixtures allow known data to be statically pre-loaded into database tables before testing. Factories create only whatever is needed on a case by case basis.

==Fixtures Advantages==

* Easy to view all the data in one place
* Data is truly static
* Simple and clean

==Fixtures Disadvantages==

* Inserting data into the database for each run slows down the testing process
* Introduces dependency on fixture data
* Data customization is more complex
* Fixtures cannot be parameterized

==Factories Advantages==

* Maintains independence of tests
*

==Factories Disadvantages==

* Complex relationships might be hard to capture

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-26T23:20:54Z

Varjun2:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture for a post:

post_one:
title: one
description: post_one_desc
category: category_one

post_two:
title: two
description: post_two_desc
category: category_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category
one, post_one_desc, category_one
two, post_two_desc, category_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl<ref>https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md</ref>, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

The following example shows how a factory can be defined using Factory Girl:

Factory.define :post do |p|
p.title 'Fixtures and Factories'
p.description 'This a wiki for fixtures and factories'
p.category 'OOLS'
end

=Fixtures vs. Factories=

Fixtures allow known data to be statically pre-loaded into database tables before testing. Factories only create whatever is needed on a case by case basis.

==Fixtures Advantages==

* Easy to view all the data in one place
* Data is truly static
*

==Fixtures Disadvantages==

* Inserting data into the database for each run slows down the testing process
* Introduces dependency on fixture data

==Factories Advantages==

* Maintains independence of tests
*

==Factories Disadvantages==

* Complex relationships might be hard to capture

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-26T22:47:39Z

Varjun2:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one

post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

Factory.define :user do |u|
u.first_name 'John'
u.last_name 'Doe'
u.admin false
end

=Fixtures vs. Factories=

==Fixtures Advantages==

==Fixtures Disadvantages==

==Factories Advantages==

==Factories Disadvantages==

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch2a 2w33 pv

2012-10-26T22:42:16Z

Varjun2:

<big>'''SaaS - 5.5 - Fixtures and Factories'''</big>

=Introduction=
One of the best parts about [http://www.ruby-lang.org/en/ Ruby] community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models), functional (for controllers) and integration tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>

=Fixtures=
Fixtures are sample data on which all the tests run.

There can be 3 types of fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref>:

1. YAML fixtures

2. CSV fixtures

3. Single-file fixtures

==YAML Fixtures==
YAML is a recursive acronym for "YAML Ain't Markup Language".<ref>http://en.wikipedia.org/wiki/YAML</ref> YAML is a file format which describes data structures in a non-verbose, human-readable format. YAML consists of name-value pairs within a hierarchy, and indentation indicates where in the hierarchy a particular name-value pair exists. This file ends with .yml extension.

The following example shows the format of a YAML fixture:

post_one:
title: one
description: post_one_desc
category: category_one
user: user_one

post_two:
title: two
description: post_two_desc
category: category_two
user: user_two

==CSV fixtures==
Comma Separated Value format can be used to store sample data. The files end with ".csv" extension. The first line of the CSV file is a comma-separated list of field names. The rest of the file contains the actual data. CSV fixtures have no fixture names.

The following example shows the format of a CSV fixture:

title,description, category, user
one, post_one_desc, category_one, user_one
two, post_two_desc, category_two, user_two

==Single-file fixtures==
Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory appointed by ActiveSupport::TestCase.fixture_path=(path). Each text file placed in this directory represents a "record". Usually these types of fixtures are named without extensions.

The following example shows the format of a single-file fixture:

posts/post_one
posts/post_two

Fixtures are basically Hash objects<ref>http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures</ref>. We can access the hash object directly because it is automatically setup as a local variable of the test case. For example:

# this will return the Hash for the fixture named post_one
posts(:post_one)

=Factories=
For a small site, fixtures are enough. However, in bigger sites fixtures might get confusing. Factories are alternatives to fixtures in such cases. They have become increasingly popular in the last few years since they allow you to do things that cannot be done using YAML.

A factory is an object used to create other objects. Factory objects are used in [http://en.wikipedia.org/wiki/Test-driven_development test-driven development] to allow the classes to be put under test.

Factory Girl<ref>https://github.com/thoughtbot/factory_girl</ref> is one of the well known factories which is widely used. It is written by Thoughtbot company and is available as a Ruby gem. Unlike fixtures, Factory Girl allows us to create objects rather than use defaults.

To set up Factory Girl, update the GemFile with the following
gem "factory_girl_rails", "~> 4.0"

Factory.define :user do |u|
u.first_name 'John'
u.last_name 'Doe'
u.admin false
end

=Fixtures vs. Factories=

=Also see=

= References =
<references />

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T23:44:41Z

Varjun2:

'''Object-Oriented Domain-Specific Languages (OODSL)'''
An OODSL<ref>OODSL 1[http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=User:Snateka&printable=yes]</ref><ref>OODSL 2[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch2_S23_GP]</ref> is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OO languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==

OO languages can be either general purpose like C++, Java and Ruby, or domain specific, like Jquery and Kiddo. The following example shows how the two kinds of languages would work if used in the real world.

'''The General Purpose Programming way of ordering hash browns at Waffle House'''<ref>Building DSLs [http://www.code-magazine.com/article.aspx?quickid=0902041&page=1]</ref>

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Now cut some jalapeno peppers and spread on the potatoes. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

I would like it Scattered, Smothered, and Peppered please. Thanks!

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL<ref>DSL examples[http://www.semanticdesigns.com/products/DMS/DomainSpecificLanguage.html]</ref> is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OO) is a programming paradigm that tries to apply real world principles to make programming easier. OO has been around since the 1950's. Starting with Simula and Smalltalk, OO languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OO languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware brings down the time taken for design by several notches and still results in good optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to start from scratch or use a tool that is already available. Creating a language from scratch gives the programmer a certain amount of flexibility to define it the way he wants to, but it takes a lot of time. Therefore, in general, software tools are used to aid in the process of creating Domain Specific Languages. This is because it not only saves time, but also helps to make the language easy to use due to familiarity with the syntax of the underlying language.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language that is used to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes their creation easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than paying much attention to the internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> Visual tools are used that help focus on the business requirements of the OODSL rather than worrying about how it works internally.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java, making designing of new OODSLs easier and similar to programming in Java. [http://java.dzone.com/articles/groovy-dsl-simple-example<code>An example for developing an OODSL in Groovy</code>].

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with an OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. Non-OODSLs are domain specific languages that do not necessarily embrace object oriented concepts like abstraction, polymorphism etc. OODSLs can be well suited for some situations whereas in other situations, they might be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

== Advantages and Disadvantages ==
Some of the advantages of OODSLs would be:
* Since OODSLs, by their name, are object oriented, they give the developer an easier alternative to model their applications based on business goals and using real world paradigms.
* Because of their object oriented nature, the code is generally simple to understand and therefore code maintenance would be easier in OODSLs than in non-OODSLs.
* Object oriented concepts like encapsulation and abstraction give the code better security when they are modified in the future.

Though OODSLs in general have several advantages over other languages, one must also consider their disadvantages:
* Defining an object oriented language in general takes more time than defining a normal language because we have to properly define it to include OO concepts.
* They may not be well-suited for all domains and environments. Sometimes there may be a simpler non-OODSL way to achieve the task.

== A Running Example ==
Given here is a simple example <ref>Example DSL in groovy[http://java.dzone.com/articles/groovy-dsl-simple-example]</ref> for creating an OODSL. This is defined in [http://en.wikipedia.org/wiki/Groovy_(programming_language)<code>Groovy</code>].

The definition of our new OODSL is as follows:
<pre>
package com.solutionsfit.dsl.memotemplate
import groovy.xml.MarkupBuilder
class MemoDsl {
String toString
String fromString
String messageString
def sections = []
/**
* Make a closure. Main definition of the DSL program
*/
def static make(closure) {
MemoDsl memoDsl = new MemoDsl()
closure.delegate = memoDsl
closure()
}
/**
* Store the values in the local variables
*/
def to(String toString){
this.toString = toString
}
def from(String fromText){
this.fromString = bodyString
}
def message(String messageString){
this.messageString = messageString
}
/**
* The getText method gets called by the DSL by delegation
*/
def getText(){
doText(this)
}
private static doText(MemoDsl memodsl){
String template = "Memo\nTo: ${memoDsl.toText}\nFrom: ${memoDsl.fromText}\n${memoDsl.body}\n"
def sectionStrings =""
for (s in memoDsl.sections) {
sectionStrings += s.title.toUpperCase() + "\n" + s.body + "\n"
}
template += sectionStrings
println template
}
}
</pre>

A sample program in our newly developed OODSL would be:
<pre>
package com.solutionsfit.dsl.memotemplate

class MemolDslTest extends GroovyTestCase {
void testDslUsage_outputText() {
MemoDsl.make {
to "Nirav Assar"
from "Barack Obama"
message "How are things? We are doing well. Take care"
text
}
}
}
</pre>

The OODSL simply displays the to, from and message values on the screen. This can be extended to perform more computations.

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T23:43:42Z

Varjun2:

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T23:40:00Z

Varjun2:

'''Object-Oriented Domain-Specific Languages (OODSL)'''
An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OO languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==

OO languages can be either general purpose like C++, Java and Ruby, or domain specific, like Jquery and Kiddo. The following example shows how the two kinds of languages would work if used in the real world.

'''The General Purpose Programming way of ordering hash browns at Waffle House'''<ref>Building DSLs [http://www.code-magazine.com/article.aspx?quickid=0902041&page=1]</ref>

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Now cut some jalapeno peppers and spread on the potatoes. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

I would like it Scattered, Smothered, and Peppered please. Thanks!

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL<ref>DSL examples[http://www.semanticdesigns.com/products/DMS/DomainSpecificLanguage.html]</ref> is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OO) is a programming paradigm that tries to apply real world principles to make programming easier. OO has been around since the 1950's. Starting with Simula and Smalltalk, OO languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OO languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware brings down the time taken for design by several notches and still results in good optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to start from scratch or use a tool that is already available. Creating a language from scratch gives the programmer a certain amount of flexibility to define it the way he wants to, but it takes a lot of time. Therefore, in general, software tools are used to aid in the process of creating Domain Specific Languages. This is because it not only saves time, but also helps to make the language easy to use due to familiarity with the syntax of the underlying language.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language that is used to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes their creation easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than paying much attention to the internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> Visual tools are used that help focus on the business requirements of the OODSL rather than worrying about how it works internally.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java, making designing of new OODSLs easier and similar to programming in Java. [http://java.dzone.com/articles/groovy-dsl-simple-example<code>An example for developing an OODSL in Groovy</code>].

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with an OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. Non-OODSLs are domain specific languages that do not necessarily embrace object oriented concepts like abstraction, polymorphism etc. OODSLs can be well suited for some situations whereas in other situations, they might be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

== Advantages and Disadvantages ==
Some of the advantages of OODSLs would be:
* Since OODSLs, by their name, are object oriented, they give the developer an easier alternative to model their applications based on business goals and using real world paradigms.
* Because of their object oriented nature, the code is generally simple to understand and therefore code maintenance would be easier in OODSLs than in non-OODSLs.
* Object oriented concepts like encapsulation and abstraction give the code better security when they are modified in the future.

Though OODSLs in general have several advantages over other languages, one must also consider their disadvantages:
* Defining an object oriented language in general takes more time than defining a normal language because we have to properly define it to include OO concepts.
* They may not be well-suited for all domains and environments. Sometimes there may be a simpler non-OODSL way to achieve the task.

== A Running Example ==
Given here is a simple example <ref>Example DSL in groovy[http://java.dzone.com/articles/groovy-dsl-simple-example]</ref> for creating an OODSL. This is defined in [http://en.wikipedia.org/wiki/Groovy_(programming_language)<code>Groovy</code>].

The definition of our new OODSL is as follows:
<pre>
package com.solutionsfit.dsl.memotemplate
import groovy.xml.MarkupBuilder
class MemoDsl {
String toString
String fromString
String messageString
def sections = []
/**
* Make a closure. Main definition of the DSL program
*/
def static make(closure) {
MemoDsl memoDsl = new MemoDsl()
closure.delegate = memoDsl
closure()
}
/**
* Store the values in the local variables
*/
def to(String toString){
this.toString = toString
}
def from(String fromText){
this.fromString = bodyString
}
def message(String messageString){
this.messageString = messageString
}
/**
* The getText method gets called by the DSL by delegation
*/
def getText(){
doText(this)
}
private static doText(MemoDsl memodsl){
String template = "Memo\nTo: ${memoDsl.toText}\nFrom: ${memoDsl.fromText}\n${memoDsl.body}\n"
def sectionStrings =""
for (s in memoDsl.sections) {
sectionStrings += s.title.toUpperCase() + "\n" + s.body + "\n"
}
template += sectionStrings
println template
}
}
</pre>

The program in the newly defined language will be:
<pre>
package com.solutionsfit.dsl.memotemplate

class MemolDslTest extends GroovyTestCase {
void testDslUsage_outputText() {
MemoDsl.make {
to "Nirav Assar"
from "Barack Obama"
message "How are things? We are doing well. Take care"
text
}
}
}
</pre>

The OODSL simply displays the to, from and message values on the screen. This can be extended to perform more computations.

== References ==
<references/>
[[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch2_S23_GP]]

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T23:31:11Z

Varjun2:

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T23:30:32Z

Varjun2:

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T23:28:55Z

Varjun2:

'''Object-Oriented Domain-Specific Languages (OODSL)'''
An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OO languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==

OO languages can be either general purpose like C++, Java and Ruby, or domain specific, like Jquery and Kiddo. The following example shows how the two kinds of languages would work if used in the real world.

'''The General Purpose Programming way of ordering hash browns at Waffle House'''<ref>Home[http://www.code-magazine.com/article.aspx?quickid=0902041&page=1]</ref>

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Now cut some jalapeno peppers and spread on the potatoes. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

I would like it Scattered, Smothered, and Peppered please. Thanks!

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL<ref>DSL Home[http://www.semanticdesigns.com/products/DMS/DomainSpecificLanguage.html]</ref> is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OO) is a programming paradigm that tries to apply real world principles to make programming easier. OO has been around since the 1950's. Starting with Simula and Smalltalk, OO languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OO languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware brings down the time taken for design by several notches and still results in good optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to start from scratch or use a tool that is already available. Creating a language from scratch gives the programmer a certain amount of flexibility to define it the way he wants to, but it takes a lot of time. Therefore, in general, software tools are used to aid in the process of creating Domain Specific Languages. This is because it not only saves time, but also helps to make the language easy to use due to familiarity with the syntax of the underlying language.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language that is used to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes their creation easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than paying much attention to the internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> Visual tools are used that help focus on the business requirements of the OODSL rather than worrying about how it works internally.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java, making designing of new OODSLs easier and similar to programming in Java. [http://java.dzone.com/articles/groovy-dsl-simple-example<code>An example for developing an OODSL in Groovy</code>].

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with an OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. Non-OODSLs are domain specific languages that do not necessarily embrace object oriented concepts like abstraction, polymorphism etc. OODSLs can be well suited for some situations whereas in other situations, they might be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

== Advantages and Disadvantages ==
Some of the advantages of OODSLs would be:
* Since OODSLs, by their name, are object oriented, they give the developer an easier alternative to model their applications based on business goals and using real world paradigms.
* Because of their object oriented nature, the code is generally simple to understand and therefore code maintenance would be easier in OODSLs than in non-OODSLs.
* Object oriented concepts like encapsulation and abstraction give the code better security when they are modified in the future.

Though OODSLs in general have several advantages over other languages, one must also consider their disadvantages:
* Defining an object oriented language in general takes more time than defining a normal language because we have to properly define it to include OO concepts.
* They may not be well-suited for all domains and environments. Sometimes there may be a simpler non-OODSL way to achieve the task.

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T23:23:55Z

Varjun2:

'''Object-Oriented Domain-Specific Languages (OODSL)'''
An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OO languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==

OO languages can be either general purpose like C++, Java and Ruby, or domain specific, like Jquery and Kiddo. The following example shows how the two kinds of languages would work if used in the real world.

'''The General Purpose Programming way of ordering hash browns at Waffle House'''

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Now cut some jalapeno peppers and spread on the potatoes. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

I would like it Scattered, Smothered, and Peppered please. Thanks!

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OO) is a programming paradigm that tries to apply real world principles to make programming easier. OO has been around since the 1950's. Starting with Simula and Smalltalk, OO languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OO languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware brings down the time taken for design by several notches and still results in good optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to start from scratch or use a tool that is already available. Creating a language from scratch gives the programmer a certain amount of flexibility to define it the way he wants to, but it takes a lot of time. Therefore, in general, software tools are used to aid in the process of creating Domain Specific Languages. This is because it not only saves time, but also helps to make the language easy to use due to familiarity with the syntax of the underlying language.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language that is used to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes their creation easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than paying much attention to the internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> Visual tools are used that help focus on the business requirements of the OODSL rather than worrying about how it works internally.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java, making designing of new OODSLs easier and similar to programming in Java. [http://java.dzone.com/articles/groovy-dsl-simple-example<code>An example for developing an OODSL in Groovy</code>].

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with an OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. Non-OODSLs are domain specific languages that do not necessarily embrace object oriented concepts like abstraction, polymorphism etc. OODSLs can be well suited for some situations whereas in other situations, they might be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

== Advantages and Disadvantages ==
Some of the advantages of OODSLs would be:
* Since OODSLs, by their name, are object oriented, they give the developer an easier alternative to model their applications based on business goals and using real world paradigms.
* Because of their object oriented nature, the code is generally simple to understand and therefore code maintenance would be easier in OODSLs than in non-OODSLs.
* Object oriented concepts like encapsulation and abstraction give the code better security when they are modified in the future.

Though OODSLs in general have several advantages over other languages, one must also consider their disadvantages:
* Defining an object oriented language in general takes more time than defining a normal language because we have to properly define it to include OO concepts.
* They may not be well-suited for all domains and environments. Sometimes there may be a simpler non-OODSL way to achieve the task.

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T23:10:08Z

Varjun2:

'''Object-Oriented Domain-Specific Languages (OODSL)'''
An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OO languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==

OO languages can be either general purpose like C++, Java and Ruby, or domain specific, like Jquery and Kiddo. The following example shows how the two kinds of languages would work if used in the real world.

'''The General Purpose Programming way of ordering hash browns at Waffle House'''

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Now cut some jalapeno peppers and spread on the potatoes. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

I would like it Scattered, Smothered, and Peppered please. Thanks!

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OO) is a programming paradigm that tries to apply real world principles to make programming easier. OO has been around since the 1950's. Starting with Simula and Smalltalk, OO languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OO languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can also be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is being sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to start from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> The tool shows visual tools that helps focus on the business requirements of the OODSL rather than worrying about the internals of its working.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java making designing of new DSLs easier and similar to programming in Java. [http://java.dzone.com/articles/groovy-dsl-simple-example<code>An example for developing an OODSL in Groovy</code>].

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. Non-OODSLs are domain specific languages that do not necessarily embrace object oriented concepts like abstraction, polymorphism etc. OODSLs can be suited well for some situations whereas other situations, it might be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

== Advantages and Disadvantages ==
Some of the advantages of OODSLs would be:
* Since OODSLs, by their name, are object oriented, they give the developer an easier alternative to model their applications based on business goals and real world.
* Because of their object oriented nature, the code is generally simple to understand and therefore code maintenance would be easier in OODSLs than non-OODSLs.
* Object oriented concepts like encapsulation and abstraction give the code better security when they are modified in the future.

Though OODSLs in general have several advantages over other languages, one can also consider their disadvantages:
* Defining an object oriented language in general takes more time than defining a normal language because we have to properly define it to include OO concepts.
* They may not be well-suited for all domains and environments. Sometimes there may be a simpler non-OODSL way to achieve the task.

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T23:07:34Z

Varjun2:

'''Object-Oriented Domain-Specific Languages (OODSL)'''
An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OO languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==

OO languages can be either general purpose like C++, Java and Ruby, or domain specific, like Jquery and Kiddo. The following example shows how the two kinds of languages would work if used in the real world.

'''The General Purpose Programming way of ordering hash browns at Waffle House'''

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Now cut some jalapeno peppers and spread on the potatoes. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

I would like it Scattered, Smothered, and Peppered please. Thanks!

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language. This page is more an attempt to bring out the shades of grey that accompany OODSLs than it is to define it.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OO) is a programming paradigm that tries to apply real world principles to make programming easier. OO has been around since the 1950's. Starting with Simula and Smalltalk, OO languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OO languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can also be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is being sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to start from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> The tool shows visual tools that helps focus on the business requirements of the OODSL rather than worrying about the internals of its working.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java making designing of new DSLs easier and similar to programming in Java.

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. Non-OODSLs are domain specific languages that do not necessarily embrace object oriented concepts like abstraction, polymorphism etc. OODSLs can be suited well for some situations whereas other situations, it might be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

== Advantages and Disadvantages ==
Some of the advantages of OODSLs would be:
* Since OODSLs, by their name, are object oriented, they give the developer an easier alternative to model their applications based on business goals and real world.
* Because of their object oriented nature, the code is generally simple to understand and therefore code maintenance would be easier in OODSLs than non-OODSLs.
* Object oriented concepts like encapsulation and abstraction give the code better security when they are modified in the future.

Though OODSLs in general have several advantages over other languages, one can also consider their disadvantages:
* Defining an object oriented language in general takes more time than defining a normal language because we have to properly define it to include OO concepts.
* They may not be well-suited for all domains and environments. Sometimes there may be a simpler non-OODSL way to achieve the task.

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T22:58:31Z

Varjun2:

An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==

OO languages can be either general purpose like C++, Java and Ruby, or domain specific, like Jquery and Kiddo. The following example shows how the two kinds of languages would work if used in the real world.

'''The General Purpose Programming way of ordering hash browns at Waffle House'''

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Now cut some jalapeno peppers and spread on the potatoes. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

I would like it Scattered, Smothered, and Peppered please. Thanks!

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language. This page is more an attempt to bring out the shades of grey that accompany OODSLs than it is to define it.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can also be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is being sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to start from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> The tool shows visual tools that helps focus on the business requirements of the OODSL rather than worrying about the internals of its working.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java making designing of new DSLs easier and similar to programming in Java.

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. Non-OODSLs are domain specific languages that do not necessarily embrace object oriented concepts like abstraction, polymorphism etc. OODSLs can be suited well for some situations whereas other situations, it might be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

== Advantages and Disadvantages ==
Some of the advantages of OODSLs would be:
* Since OODSLs, by their name, are object oriented, they give the developer an easier alternative to model their applications based on business goals and real world.
* Because of their object oriented nature, the code is generally simple to understand and therefore code maintenance would be easier in OODSLs than non-OODSLs.
* Object oriented concepts like encapsulation and abstraction give the code better security when they are modified in the future.

Though OODSLs in general have several advantages over other languages, one can also consider their disadvantages:
* Defining an object oriented language in general takes more time than defining a normal language because we have to properly define it to include OO concepts.
* They may not be well-suited for all domains and environments. Sometimes there may be a simpler non-OODSL way to achieve the task.

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T22:51:13Z

Varjun2:

An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==

OO languages can be either general purpose like C++, Java and Ruby, or domain specific, like Jquery and Kiddo. The following example shows how the two kinds of languages would work if used in the real world.

'''The General Purpose Programming way of ordering hash browns at Waffle House'''

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Now cut some jalapeno peppers and spread on the potatoes. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

I would like it Scattered, Smothered, and Peppered please. Thanks!

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language. This page is more an attempt to bring out the shades of grey that accompany OODSLs than it is to define it.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can also be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is being sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to start from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> The tool shows visual tools that helps focus on the business requirements of the OODSL rather than worrying about the internals of its working.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java making designing of new DSLs easier and similar to programming in Java.

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. OODSLs can be suited well for some situations whereas on some situations, it may be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is a non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

== Advantages and Disadvantages ==
Some of the advantages of OODSLs would be:
* Since OODSLs, by their name, are object oriented, they give the developer an easier alternative to model their applications based on business goals and real world.
* Because of their object oriented nature, the code is generally simple to understand and therefore code maintenance would be easier in OODSLs than non-OODSLs.
*

== Conclusion ==

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T22:41:15Z

Varjun2: /* Overview */

An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==
'''The General Purpose Programming way of ordering hash browns at Waffle House'''

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Now cut some jalapeno peppers and spread on the potatoes. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

I would like it Scattered, Smothered, and Peppered please. Thanks!

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language. This page is more an attempt to bring out the shades of grey that accompany OODSLs than it is to define it.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can also be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is being sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to scratch from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> The tool shows visual tools that helps focus on the business requirements of the OODSL rather than worrying about the internals of its working.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java making designing of new DSLs easier and similar to programming in Java.

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. OODSLs can be suited well for some situations whereas on some situations, it may be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is a non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

== Advantages and Disadvantages ==

== Conclusion ==

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T22:36:29Z

Varjun2:

An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==
'''The General Purpose Programming way of ordering hash browns at Waffle House'''

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

Scattered, Smothered, and Covered

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language. This page is more an attempt to bring out the shades of grey that accompany OODSLs than it is to define it.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can also be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is being sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to scratch from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> The tool shows visual tools that helps focus on the business requirements of the OODSL rather than worrying about the internals of its working.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java making designing of new DSLs easier and similar to programming in Java.

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. OODSLs can be suited well for some situations whereas on some situations, it may be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is a non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

== Advantages and Disadvantages ==

== Conclusion ==

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T22:29:02Z

Varjun2:

An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==
'''The General Purpose Programming way of ordering hash browns at Waffle House'''

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

Scattered, smothered, and covered

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language. This page is more an attempt to bring out the shades of grey that accompany OODSLs than it is to define it.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can also be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is being sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to scratch from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> The tool shows visual tools that helps focus on the business requirements of the OODSL rather than worrying about the internals of its working.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java making designing of new DSLs easier and similar to programming in Java.

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. OODSLs can be suited well for some situations whereas on some situations, it may be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is a non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

== Advantages and Disadvantages ==

== Conclusion ==

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T22:28:07Z

Varjun2:

An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==
'''The General Purpose Programming way of ordering hash browns at Waffle House'''

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Then add cheese, which you can get by milking a cow and.....

'''The OODSL way of ordering hash browns at Waffle House'''

Scattered, smothered, and covered

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

* Internal
* External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language. This page is more an attempt to bring out the shades of grey that accompany OODSLs than it is to define it.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can also be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is being sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to scratch from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> The tool shows visual tools that helps focus on the business requirements of the OODSL rather than worrying about the internals of its working.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java making designing of new DSLs easier and similar to programming in Java.

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc.

== Advantages and Disadvantages ==

== Conclusion ==

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T22:22:46Z

Varjun2:

An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==
'''The general purpose programming way of ordering hash browns at Waffle House'''

There is a plant called a potato, which is a tuber, a root plant. Take the potato, harvest it, wash it off, and chop it into little cubes. Put those in a pan with oil and fry them until they are just turning brown, and then drain the grease away and put them on a plate. OK, next I want cheese. There’s an animal called a cow...

'''The OODSL way of ordering hash browns at Waffle House'''

Scattered, smothered, and covered

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

Internal
External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language. This page is more an attempt to bring out the shades of grey that accompany OODSLs than it is to define it.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can also be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is being sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to scratch from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> The tool shows visual tools that helps focus on the business requirements of the OODSL rather than worrying about the internals of its working.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java making designing of new DSLs easier and similar to programming in Java.

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc.

== Advantages and Disadvantages ==

== Conclusion ==

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T22:22:14Z

Varjun2:

An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==
'''The general purpose programming way of ordering hash browns at Waffle House'''

There is a plant called a potato, which is a tuber, a root plant. Take the potato, harvest it, wash it off, and chop it into little cubes. Put those in a pan with oil and fry them until they are just turning brown, and then drain the grease away and put them on a plate. OK, next I want cheese. There’s an animal called a cow...

'''The OODSL way of ordering hash browns at Waffle House'''

Scattered, smothered, and covered

For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.

OODSLs can be of 2 types:

Internal
External

Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language. This page is more an attempt to bring out the shades of grey that accompany OODSLs than it is to define it.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can also be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is being sent to the client.

=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Tools for Creating OODSL ==
When creating an OODSL, one can either choose to scratch from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> The tool shows visual tools that helps focus on the business requirements of the OODSL rather than worrying about the internals of its working.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java making designing of new DSLs easier and similar to programming in Java.

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc.

== Advantages and Disadvantages ==

== Conclusion ==

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T22:01:15Z

Varjun2:

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T21:53:29Z

Varjun2:

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T21:53:04Z

Varjun2:

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T21:49:52Z

Varjun2:

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T21:49:33Z

Varjun2:

An OODSL is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) language that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==
'''General purpose programming way of ordering hash browns at Waffle House'''
internal, external

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Creating OODSL ==
When creating an OODSL, one can either choose to scratch from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>http://boo.codehaus.org/Home</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref>

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc.

== Advantages and Disadvantages ==

== Conclusion ==

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T21:48:07Z

Varjun2:

An OODSL is a '''[[http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>]]''' '''(DSL)''' language that exhibits characteristics that have traditionally been attributed to '''[[http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>]]''' 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==
'''General purpose programming way of ordering hash browns at Waffle House'''
internal, external

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Creating OODSL ==
When creating an OODSL, one can either choose to scratch from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>http://boo.codehaus.org/Home</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

=== Visual Studio ===
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref>

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc.

== Advantages and Disadvantages ==

== Conclusion ==

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T21:36:36Z

Varjun2:

An OODSL is a '''[[Domain-specific language]]''' '''(DSL)''' language that exhibits characteristics that have traditionally been attributed to '''[[Object-Oriented Languages]]''' 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==
internal, external

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Creating OODSL ==
When creating an OODSL, one can either choose to scratch from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo<ref>http://boo.codehaus.org/Home</ref> is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc.

== Advantages and Disadvantages ==

== Conclusion ==

== References ==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T21:29:25Z

Varjun2:

An OODSL is a '''[[Domain-specific language]]''' '''(DSL)''' language that exhibits characteristics that have traditionally been attributed to '''[[Object-Oriented Languages]]''' 

Although OOP languages and Domain specific languages have been around for several years, OODSLs are relatively new.

== Overview ==

== History ==
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OOP) is a programming paradigm that tries to apply real world principles to make programming easier. OOP has been around since the 1950's. Starting with Simula and Smalltalk, OOP languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OOP languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

== Examples ==
=== OODSL compiler for FPGA ===
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays. The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware reduces the design time several times and still result in an optimal performance.

== Creating OODSL ==
When creating an OODSL, one can either choose to scratch from the scratch or use a tool that is already available to create the language. Creating a language from the scratch gives flexibility to the programmer to define it the way he wants to but it takes a lot of time. In general, some tools are used to create Domain Specific Languages. This is because it not only saves time but also helps to make the language easy to use.
=== Boo ===
Boo is an open source object oriented language to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes creation of them easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).

== OODSL vs. non-OODSL ==
When defining a DSL, choosing whether to go with a OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc.

== Advantages and Disadvantages ==

== Conclusion ==

== References ==
<references/>
* Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T21:16:22Z

Varjun2:

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T20:51:25Z

Varjun2:

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T20:49:40Z

Varjun2:

'''[Domain-specific object-oriented languages (OODSLs)]'''

An OODSL is a '''[[Domain-specific language]]''' '''(DSL)'''[http://en.wikipedia.org/wiki/Domain-specific_language] language that exhibits characteristics that have traditionally been attributed to '''[[Object-Oriented Languages]]''' 

== Overview ==

== History ==

== Examples ==
=== OODSL compiler for FPGA ===

== OODSL vs. non-OODSL ==

== Advantages and Disadvantages ==

== Conclusion ==

== References ==

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T20:47:34Z

Varjun2:

[http://en.wikipedia.org/wiki/Domain-specific_language]'''Domain-specific object-oriented languages (OODSLs)'''

An OODSL is a '''[[Domain-specific language]]''' '''(DSL)''' language that exhibits characteristics that have traditionally been attributed to '''[[Object-Oriented Languages]]''' 

== Overview ==

== History ==

== Examples ==
=== OODSL compiler for FPGA ===

== OODSL vs. non-OODSL ==

== Advantages and Disadvantages ==

== Conclusion ==

== References ==

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T20:46:54Z

Varjun2:

'''Domain-specific object-oriented languages (OODSLs)'''

An OODSL is a '''[[Domain-specific language]]''' '''(DSL)''' language that exhibits characteristics that have traditionally been attributed to '''[[Object-Oriented Languages]]''' 

== Overview ==

== History ==

== Examples ==
=== OODSL compiler for FPGA ===

== OODSL vs. non-OODSL ==

== Advantages and Disadvantages ==

== Conclusion ==

== References ==

CSC/ECE 517 Fall 2012/ch1 1w9 av

2012-09-14T20:38:00Z

Varjun2:

'''Domain-specific object-oriented languages''' - This page describes the domain specific object oriented languages, what languages are currently in use and how useful they are.
Object oriented domain specific languages are programming languages that are specific to some particular domain incorporating object oriented concepts. They differ from traditional languages in that they can be used only in the domain they are defined for and not for other general purposes.

== Overview ==

== History ==

== Examples ==

== OODSL vs. non-OODSL ==
hey ssup?

== Advantages and Disadvantages ==

== Conclusion ==

== References ==

CSC/ECE 517 Fall 2012

2012-09-14T20:20:50Z

Varjun2:

*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]