DOCSLIB.ORG

Record Types in Scala: Design and Evaluation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

DEGREE PROJECT IN THE FIELD OF TECHNOLOGY ENGINEERING PHYSICS AND THE MAIN FIELD OF STUDY COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2017 Record Types in Scala: Design and Evaluation OLOF KARLSSON KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF COMPUTER SCIENCE AND COMMUNICATION Record Types in Scala: Design and Evaluation OLOF KARLSSON Master in Computer Science Date: June 28, 2017 Supervisor: Philipp Haller Examiner: Mads Dam Swedish title: Record-typer för Scala: Design och utvärdering School of Computer Science and Communication i Abstract A record type is a data type consisting of a collection of named fields that combines the flexibility of associative arrays in some dynamically typed languages with the safety guarantees and possible runtime performance of static typing. The structural typing of records is especially suitable for handling semi-structured data such as JSON and XML making efficient records an attractive choice for high-performance computing and large- scale data analytics. It has proven difficult to implement record types in Scala however. Existing libraries suffer from either severe compile-time penalties, large runtime over- head, or other restrictions in usability such as poor IDE integration and hard-to-compre- hend error-messages. This thesis provides a systematic description and comparison of both existing and possible new approaches to records in Scala and Dotty, a new compiler for the Scala 3 language. A novel benchmarking suite is presented, built on top of the Java Microbench- mark Harness (JMH), for measuring runtime and compile-time performance of records running on the Java Virtual Machine and currently supporting Scala, Dotty, Java and Whiteoak. To achieve field access times comparable to nominally typed classes, it is conjectured that width subtyping has to be restricted to explicit coercion and a compilation scheme for such record types is sketched. For unordered record types with width and depth sub- typing however, hashmap-based approaches are found to have the most attractive run- time performance characteristics. In particular, Dotty provides native support for such an implementation using structural refinement types that might strike a good balance be- tween flexibility and runtime performance for records in the future. ii Sammanfattning En record-typ är en datatyp som består av en en uppsättning namngivna fält som kom- binerar flexibiliteten hos associativa arrayer i vissa dynamiskt typade programmerings- språk med säkerhetsgarantierna och den potentiella exekveringshastigheten som fås av statisk typning. Records strukturella typning är särskilt väl lämpad för att hantera semi- strukturerad data såsom JSON och XML vilket gör beräkningseffektiva records ett attrak- tivt val för högprestandaberäkningar och storskalig dataanalys. Att implementera records i programmeringsspråket Scala har dock visat sig svårt. Existerande bibliotek lider an- tingen av långa kompileringstider, långsam exekveringshastighet, eller andra problem med användbarheten såsom dålig integration med olika utvecklingsmiljöer och svårför- stådda felmeddelanden. Den här uppsatsen ger en systematisk beskrivning och jämförelse av både existeran- de och nya lösningar för records i Scala och Dotty, en ny kompilator för Scala 3. Ett nytt benchmarkingverktyg för att mäta exekveringshastigheten och kompileringstiden av re- cords som körs på den virtuella Java maskinen presenteras. Benchmarkingverktyget är byggt på Java Microbenchmark Harness (JMH) och stöder i nuläget Scala, Dotty, Java och Whiteoak. För att åstadkomma körtider som är jämförbara med nominellt typade klasser an- tas att subtypning på bredden måste begränsas till explicita konverteringsanrop och en skiss till en kompileringsstrategi för sådana records presenteras. För record-typer med ic- ke ordnade fält och subtypning på bredden och djupet visar sig istället records baserade på hashtabeller ha de mest attraktiva exekveringstiderna. Dotty tillhandahåller stöd för en sådan implementation med strukturella förfiningstyper som kan komma att träffa en bra balans mellan flexibilitet och exekveringshastighet för records i framtiden. iii Dedication To Dag, for providing shelter in times of need and always reminding me of what en- gineering is all about. I would also like to thank my friends and family for invaluable support, and A3J - thanks for all the coffee! Contents Contents v 1 Introduction 1 1.1 Problem Description and Objective . .1 1.2 Research Question and Report Structure . .2 1.3 Contribution . .2 1.4 Societal and Ethical Aspects . .2 2 Background 4 2.1 Definition of Record and Record Type . .4 2.2 Type Systems for Polymorphic Records . .5 2.2.1 Structural Subtyping . .5 2.2.2 Bounded Quantification . .7 2.2.3 Other Forms of Parametric Polymorphism . .8 2.3 The Scala Language . .8 3 Method 13 3.1 Qualitative Comparison . 14 3.2 Quantitative Comparison . 14 3.2.1 Wreckage Benchmarking Suite Generator Library . 14 3.2.2 Runtime Benchmarks . 17 3.2.3 Compile-Time Benchmarks . 18 3.2.4 Statistical treatment . 18 3.2.4.1 Runtime Benchmarks . 19 3.2.4.2 Compile-Time benchmarks . 20 4 Description of Existing Approaches 21 4.1 Scala’s Structural Refinement Types . 21 4.1.1 Basic Features . 22 4.1.2 Implementation . 24 4.2 scala-records v0.3 . 24 4.2.1 Basic Features . 25 4.2.2 Lack of Explicit Types . 26 4.2.3 Other Features . 28 4.3 scala-records v0.4 . 28 4.3.1 Basic Features . 29 4.3.2 Explicit Types . 30 v vi CONTENTS 4.3.3 Other Features . 31 4.4 Compossible . 31 4.4.1 Creation through Extension through Concatenation . 31 4.4.2 Extension and (Unchecked) Update . 33 4.4.3 Access and Select . 33 4.4.4 Explicit Types . 34 4.4.5 Polymorphism . 35 4.4.6 Other Features . 36 4.5 Shapeless 2.3.2 . 37 4.5.1 HList Records . 37 4.5.2 Create . 38 4.5.3 Field Access . 39 4.5.4 Explicit Types . 41 4.5.5 Subtyping . 42 4.5.6 Parametric Polymorphism . 42 4.5.7 Other Type Classes . 43 4.5.8 HCons Extension . 46 4.6 Dotty’s New Structural Refinement Types . 47 4.6.1 Implementation . 47 4.6.2 Basic Features . 48 4.6.3 Polymorphism . 50 4.6.4 Extension . 51 4.6.5 Update . 54 5 Comparison of Existing Approaches 56 5.1 Qualitative Comparison . 56 5.2 Quantitative Evaluation using Benchmark . 58 5.2.1 Runtime performance . 58 5.2.1.1 Creation Time against Record Size . 58 5.2.1.2 Access Time against Field Index . 58 5.2.1.3 Access Time against Record Size . 59 5.2.1.4 Access Time against Degree of Polymorphism . 60 5.2.2 Compile-Time Performance . 62 5.2.2.1 Create . 62 5.2.2.2 Create and Access All Fields . 62 6 Analysis and Possible new Approaches 65 6.1 Strengths and Weaknesses of Existing Approaches . 65 6.2 Design Space for Records . 66 6.3 Record Type Representations . 67 6.4 Compilation Schemes for Subtyped Records . 68 6.4.1 P −W −D±: No Permutation, No Width Subtyping . 68 6.4.2 P −W +D±: Width Subtyping for Ordered Fields . 69 6.4.3 P +W −D±: Unordered Records without Width Subtyping . 69 6.4.4 P +W +D±: Unordered Records with Width Subtyping . 69 6.4.4.1 Option 1: Searching . 70 6.4.4.2 Option 2: Information Passing . 70 CONTENTS vii 6.4.4.3 Option 3: Use the JVM . 72 6.4.5 Summary . 73 6.5 Benchmarks of Possible Data Structures . 75 6.5.1 Access Time against Record Size . 75 6.5.2 Access Time against Degree of Polymorphism . 75 7 Discussion and Future Work 78 7.1 Subtyping and Field Access . 78 7.2 Type-level Operations . 79 7.3 Not One but Three Record Types to Rule Them All? . 79 7.4 Future work . 80 8 Related Work 81 8.1 Theoretical Foundations . 81 8.2 Structural Types on the JVM . 81 9 Conclusions 83 Bibliography 85 A Whiteoak 2.1 Benchmarks 89 Chapter 1 Introduction Software is getting more and more complex and programming languages need to con- stantly evolve to help programmers cut through this complexity. In a perfect world it is effortless to develop systems in a short amount of time that are easy to understand, maintain and augment while at the same time being robust with few bugs, high run- time performance and low operating cost. In the real world however, there do not seem to be a silver bullet and these factors have to be weighted against each other. Different programming paradigms tend to focus more on some aspects at the expense of others; Scripting languages emphasize rapid development and syntactic simplicity while com- piled languages tend to focus more on robustness and runtime efficiency. Scala is a statically typed language with lightweight syntax that is designed to pro- vide a middle-ground between these two extremes. It is a multi-paradigm language com- bining the virtues of object-oriented and functional programming, and an advanced type system is combined with local type inference to lessen the syntactic burden [1]. Further- more, Scala has its theoretical foundation in the vObj calculus [2], recently replaced by DOT [3], which combines nominally typed classes and objects with structural typing. It is therefore natural to consider the possibility of extending the Scala language with struc- turally typed records. A record-type is a collection of named fields that combines the flexibility of associa- tive arrays in some dynamically-typed languages with the safety guarantees of static typ- ing. Structural typing opens up several possibilities for record polymorphism, including width and depth subtyping, making records especially suitable for handling complex and semi-structured heterogeneous data such as JSON and XML. Together with the safety benefits and potential run-time performance of static typing, this makes records an at- tractive choice for high performance computing and large-scale data analytics and a po- tentially valuable addition to the Scala language.
Recommended publications
  • 1=Haskell =1=Making Our Own Types and Typeclasses

    1=Haskell =1=Making Our Own Types and Typeclasses

    Haskell Making Our Own Types and Typeclasses http://igm.univ-mlv.fr/~vialette/?section=teaching St´ephaneVialette LIGM, Universit´eParis-Est Marne-la-Vall´ee November 13, 2016 Making Our Own Types and Typeclasses Algebraic data types intro So far, we've run into a lot of data types: Bool, Int, Char, Maybe, etc. But how do we make our own? One way is to use the data keyword to define a type. Let's see how the Bool type is defined in the standard library. data Bool= False| True data means that we're defining a new data type. Making Our Own Types and Typeclasses Algebraic data types intro data Bool= False| True The part before the = denotes the type, which is Bool. The parts after the = are value constructors. They specify the different values that this type can have. The | is read as or. So we can read this as: the Bool type can have a value of True or False. Both the type name and the value constructors have to be capital cased. Making Our Own Types and Typeclasses Algebraic data types intro We can think of the Int type as being defined like this: data Int=-2147483648|-2147483647| ...|-1|0|1|2| ...| 2147483647 The first and last value constructors are the minimum and maximum possible values of Int. It's not actually defined like this, the ellipses are here because we omitted a heapload of numbers, so this is just for illustrative purposes. Shape let's think about how we would represent a shape in Haskell.
  • A Polymorphic Type System for Extensible Records and Variants

    A Polymorphic Type System for Extensible Records and Variants

    A Polymorphic Typ e System for Extensible Records and Variants Benedict R. Gaster and Mark P. Jones Technical rep ort NOTTCS-TR-96-3, November 1996 Department of Computer Science, University of Nottingham, University Park, Nottingham NG7 2RD, England. fbrg,[email protected] Abstract b oard, and another indicating a mouse click at a par- ticular p oint on the screen: Records and variants provide exible ways to construct Event = Char + Point : datatyp es, but the restrictions imp osed by practical typ e systems can prevent them from b eing used in ex- These de nitions are adequate, but they are not par- ible ways. These limitations are often the result of con- ticularly easy to work with in practice. For example, it cerns ab out eciency or typ e inference, or of the di- is easy to confuse datatyp e comp onents when they are culty in providing accurate typ es for key op erations. accessed by their p osition within a pro duct or sum, and This pap er describ es a new typ e system that reme- programs written in this way can b e hard to maintain. dies these problems: it supp orts extensible records and To avoid these problems, many programming lan- variants, with a full complement of p olymorphic op era- guages allow the comp onents of pro ducts, and the al- tions on each; and it o ers an e ective type inference al- ternatives of sums, to b e identi ed using names drawn gorithm and a simple compilation metho d.
  • Design and Implementation of Generics for the .NET Common Language Runtime

    Design and Implementation of Generics for the .NET Common Language Runtime

    Design and Implementation of Generics for the .NET Common Language Runtime Andrew Kennedy Don Syme Microsoft Research, Cambridge, U.K. fakeÒÒ¸d×ÝÑeg@ÑicÖÓ×ÓfغcÓÑ Abstract cally through an interface definition language, or IDL) that is nec- essary for language interoperation. The Microsoft .NET Common Language Runtime provides a This paper describes the design and implementation of support shared type system, intermediate language and dynamic execution for parametric polymorphism in the CLR. In its initial release, the environment for the implementation and inter-operation of multiple CLR has no support for polymorphism, an omission shared by the source languages. In this paper we extend it with direct support for JVM. Of course, it is always possible to “compile away” polymor- parametric polymorphism (also known as generics), describing the phism by translation, as has been demonstrated in a number of ex- design through examples written in an extended version of the C# tensions to Java [14, 4, 6, 13, 2, 16] that require no change to the programming language, and explaining aspects of implementation JVM, and in compilers for polymorphic languages that target the by reference to a prototype extension to the runtime. JVM or CLR (MLj [3], Haskell, Eiffel, Mercury). However, such Our design is very expressive, supporting parameterized types, systems inevitably suffer drawbacks of some kind, whether through polymorphic static, instance and virtual methods, “F-bounded” source language restrictions (disallowing primitive type instanti- type parameters, instantiation at pointer and value types, polymor- ations to enable a simple erasure-based translation, as in GJ and phic recursion, and exact run-time types.
  • Openflight® Scene Description Database Specification

    Openflight® Scene Description Database Specification

    OpenFlight® Scene Description Database Specification Version 15.7.0 April, 2000 USE AND DISCLOSURE OF DATA ©MultiGen-Paradigm® Inc., 2000. All rights reserved. MultiGen Inc. is the owner of all intellectual property rights, including but not limited to, copyrights in and to this book and its contents. The reader of this book is licensed to use said contents and in- tellectual property in any lawful manner and for any lawful purpose; said license is non-exclusive and royalty-free. This book may not be reproduced or distributed in any form, in whole or part, without the express written permission of MultiGen-Par- adigm Inc. 550 S. Winchester Blvd., Suite 500, San Jose, CA 95128 Phone (408) 261-4100 Fax (408) 261-4103 Copyright © 2000 MultiGen-Paradigm® Inc. All Rights Reserved. OpenFlight Scene Description Database Specification,v15.7.0 (April, 2000) MultiGen-Paradigm Inc. (MultiGen-Paradigm) provides this material as is, without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a par- ticular purpose. MultiGen-Paradigm may make improvements and changes to the product described in this manual at any time without notice. MultiGen-Paradigm assumes no responsibility for the use of the product or this manual except as expressly set forth in the applicable MultiGen-Paradigm agreement or agreements and subject to terms and con- ditions set forth therein and applicable MultiGen-Paradigm policies and procedures. This manual may contain technical inaccuracies or typographical errors. Periodic changes are made to the information contained herein: these changes will be incorporated in new editions of the manual.
  • Data Format for the Interchange of Biometric and Forensic Information

    Data Format for the Interchange of Biometric and Forensic Information

    ANSI/NIST-ITL 1-2011 Data Format for the Interchange of Biometric and Forensic Information Foreword ...……………………………………………………………………………..vii 1 Introduction...................................................................................................... 1 1.1 Previous versions of the Standard ............................................................ 1 1.2 Summary of Changes for this Version of the Standard ............................. 1 2 Scope, purpose, and conformance ................................................................. 2 2.1 Scope ........................................................................................................ 2 2.2 Purpose..................................................................................................... 3 2.3 Conformance............................................................................................. 3 3 Encodings of the Standard.............................................................................. 3 4 Transmitted data conventions ......................................................................... 4 4.1 Friction Ridge Representation................................................................... 4 4.2 Byte and bit ordering ................................................................................. 4 4.3 Grayscale data .......................................................................................... 4 4.4 Binary data ................................................................................................ 5 4.5 Color data.................................................................................................
  • Java Secrets.Pdf

    Java Secrets.Pdf

    Java Secrets by Elliotte Rusty Harold IDG Books, IDG Books Worldwide, Inc. ISBN: 0764580078 Pub Date: 05/01/97 Buy It Preface About the Author Part I—How Java Works Chapter 1—Introducing Java SECRETS A Little Knowledge Can Be a Dangerous Thing What’s in This Book? Part I: How Java Works Part II: The sun Classes Part III: Platform-Dependent Java Why Java Secrets? Broader applicability More power Inspiration Where Did the Secrets Come From? Where is the documentation? The source code The API documentation What Versions of Java Are Covered? Some Objections Java is supposed to be platform independent Why aren’t these things documented? FUD (fear, uncertainty, and doubt) How secret is this, anyway? Summary Chapter 2—Primitive Data Types Bytes in Memory Variables, Values, and Identifiers Place-Value Number Systems Binary notation Hexadecimal notation Octal notation Integers ints Long, short, and byte Floating-Point Numbers Representing floating-point numbers in binary code Special values Denormalized floating-point numbers CHAR ASCII ISO Latin-1 Unicode UTF8 Boolean Cross-Platform Issues Byte order Unsigned integers Integer widths Conversions and Casting Using a cast The mechanics of conversion Bit-Level Operators Some terminology Bitwise operators Bit shift operators Summary Chapter 2—Primitive Data Types Bytes in Memory Variables, Values, and Identifiers Place-Value Number Systems Binary notation Hexadecimal notation Octal notation Integers ints Long, short, and byte Floating-Point Numbers Representing floating-point numbers in binary code
  • Lecture Slides

    Lecture Slides

    Outline Meta-Classes Guy Wiener Introduction AOP Classes Generation 1 Introduction Meta-Classes in Python Logging 2 Meta-Classes in Python Delegation Meta-Classes vs. Traditional OOP 3 Meta-Classes vs. Traditional OOP Outline Meta-Classes Guy Wiener Introduction AOP Classes Generation 1 Introduction Meta-Classes in Python Logging 2 Meta-Classes in Python Delegation Meta-Classes vs. Traditional OOP 3 Meta-Classes vs. Traditional OOP What is Meta-Programming? Meta-Classes Definition Guy Wiener Meta-Program A program that: Introduction AOP Classes One of its inputs is a program Generation (possibly itself) Meta-Classes in Python Its output is a program Logging Delegation Meta-Classes vs. Traditional OOP Meta-Programs Nowadays Meta-Classes Guy Wiener Introduction AOP Classes Generation Compilers Meta-Classes in Python Code Generators Logging Delegation Model-Driven Development Meta-Classes vs. Traditional Templates OOP Syntactic macros (Lisp-like) Meta-Classes The Problem With Static Programming Meta-Classes Guy Wiener Introduction AOP Classes Generation Meta-Classes How to share features between classes and class hierarchies? in Python Logging Share static attributes Delegation Meta-Classes Force classes to adhere to the same protocol vs. Traditional OOP Share code between similar methods Meta-Classes Meta-Classes Guy Wiener Introduction AOP Classes Definition Generation Meta-Classes in Python Meta-Class A class that creates classes Logging Delegation Objects that are instances of the same class Meta-Classes share the same behavior vs. Traditional OOP Classes that are instances of the same meta-class share the same behavior Meta-Classes Meta-Classes Guy Wiener Introduction AOP Classes Definition Generation Meta-Classes in Python Meta-Class A class that creates classes Logging Delegation Objects that are instances of the same class Meta-Classes share the same behavior vs.
  • Haskell-Style Type Classes with Isabelle/Isar

    Haskell-Style Type Classes with Isabelle/Isar

    Isar ∀ Isabelle= α λ β → Haskell-style type classes with Isabelle/Isar Florian Haftmann 20 February 2021 Abstract This tutorial introduces Isar type classes, which are a convenient mech- anism for organizing specifications. Essentially, they combine an op- erational aspect (in the manner of Haskell) with a logical aspect, both managed uniformly. 1 INTRODUCTION 1 1 Introduction Type classes were introduced by Wadler and Blott [8] into the Haskell lan- guage to allow for a reasonable implementation of overloading1. As a canon- ical example, a polymorphic equality function eq :: α ) α ) bool which is overloaded on different types for α, which is achieved by splitting introduc- tion of the eq function from its overloaded definitions by means of class and instance declarations: 2 class eq where eq :: α ) α ) bool instance nat :: eq where eq 0 0 = True eq 0 - = False eq - 0 = False eq (Suc n)(Suc m) = eq n m instance (α::eq; β::eq) pair :: eq where eq (x1; y1) (x2; y2) = eq x1 x2 ^ eq y1 y2 class ord extends eq where less-eq :: α ) α ) bool less :: α ) α ) bool Type variables are annotated with (finitely many) classes; these annotations are assertions that a particular polymorphic type provides definitions for overloaded functions. Indeed, type classes not only allow for simple overloading but form a generic calculus, an instance of order-sorted algebra [5, 6, 10]. From a software engineering point of view, type classes roughly correspond to interfaces in object-oriented languages like Java; so, it is naturally desirable that type classes do not only provide functions (class parameters) but also state specifications implementations must obey.
  • Lightning Layout Tricks

    Lightning Layout Tricks

    Welcome to @NEDreamin #NEDreamin Manchester, NH 2018 Lightning Layout Tricks Tom Hoffman @NEDreamin #NEDreamin Manchester, NH 2018 Me (@AccidentalAdmin) • Practice Lead @ Spark.Orange • Co-founded Pittsburgh Non-Profit User Group, Current Admin User Group Leader • The Accidental Admins Blog • Very active in Answer Community • Dad, Husband & Hopeless Pirates Fan • Read at least one book a week, sometimes in a day. • Top Gun is the best movie ever made…prove me wrong. @NEDreamin #NEDreamin Manchester, NH 2018 Overview & Goals Baseline Experience Simplify Innovate Understand Lightning Identify ways to Recognize when Record detail tabs, pages & how they optimized the user Lightning Pages can conditional interact with other experience to gain reduce the need for components, $User aspects of Salesforce better adoption & record types, page filtered components, results layouts, & automation and more fun. @NEDreamin #NEDreamin Manchester, NH 2018 Forward-Looking Common Sense Statement • Probably going to see a few interesting things today (I hope…) • It’s ok to experiment, but Practice Safe UX – use a sandbox • Identify a good use case & test • Roll out to small group of test users, get feedback • If it makes tasks easier and/or users happier = good • If it makes you look really smart = great (as long as ^ is true too) Make sure it makes sense – just because you can, does not mean you should. @NEDreamin #NEDreamin Manchester, NH 2018 Audience Participation Round! How many of you are with organizations that have migrated to Lightning? @NEDreamin
  • OMG Meta Object Facility (MOF) Core Specification

    OMG Meta Object Facility (MOF) Core Specification

    Date : October 2019 OMG Meta Object Facility (MOF) Core Specification Version 2.5.1 OMG Document Number: formal/2019-10-01 Standard document URL: https://www.omg.org/spec/MOF/2.5.1 Normative Machine-Readable Files: https://www.omg.org/spec/MOF/20131001/MOF.xmi Informative Machine-Readable Files: https://www.omg.org/spec/MOF/20131001/CMOFConstraints.ocl https://www.omg.org/spec/MOF/20131001/EMOFConstraints.ocl Copyright © 2003, Adaptive Copyright © 2003, Ceira Technologies, Inc. Copyright © 2003, Compuware Corporation Copyright © 2003, Data Access Technologies, Inc. Copyright © 2003, DSTC Copyright © 2003, Gentleware Copyright © 2003, Hewlett-Packard Copyright © 2003, International Business Machines Copyright © 2003, IONA Copyright © 2003, MetaMatrix Copyright © 2015, Object Management Group Copyright © 2003, Softeam Copyright © 2003, SUN Copyright © 2003, Telelogic AB Copyright © 2003, Unisys USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification.
  • Linkedin Sales Navigator for Salesforce Installation Guide

    Linkedin Sales Navigator for Salesforce Installation Guide

    LinkedIn Sales Navigator for Salesforce Installation Guide: Lightning View The installation process will take less than 30 minutes. Note: This guide is for Salesforce Lightning. If you need to install Classic, please review the guide here. The LinkedIn Sales Navigator for Salesforce Application • Allow Sales Navigator seat holders to search for people on LinkedIn and view profile details including photos, current roles, and work history from within Salesforce. • Uncover the best way to get introduced through TeamLink. • Find new leads directly in Salesforce with Lead Recommendations. • Get Account & Lead Updates including news mentions and job changes when viewing accounts in Salesforce. • Send InMail, messages, and customized connection requests from within Salesforce. Table of Contents • Before You Begin • Phase 1: Install the Application • Phase 2: Application Set Up • Phase 3: Test the Application • Additional Information and Troubleshooting Tips Recent Updates (This includes feature changes for Sales Navigator since the last Quarter Release) • Now available for Person Account types. Embedded profiles (Widget) will work for both Lightning and Classic versions of Salesforce. o Note: CRM Sync does not support Person Account types (inclusive of Write-back and Autosave Person Accounts as a contact). KEY CALLOUTS • Note: Installation of Sales Navigator will create new Record Types for Tasks and assign custom defaults. If you do not have “Task” Record Types created, this can cause Record Types for Global Actions (e.g. New Event, Log a Call, New Task, etc.) to default to "--Master--" which would remove existing Global Actions from the Activities list. • If after enablement you find that Global Actions are missing, please take the following steps: o To Start this process, navigate to Objects and Fields in the Setup menu using “Quick Find”.
  • Orthogonal to the Java Imperative?

    Orthogonal to the Java Imperative?

    Orthogonal to the Java Imperative? Suad Alagi´c, Jose Solorzano, and David Gitchell Department of Computer Science, Wichita State University Wichita, KS 67260-0083, USA [email protected] Abstract. Three nontrivial limitations of the existing JavaTM technol- ogy are considered from the viewpoint of object-oriented database tech- nology. The limitations are: lack of support for orthogonal persistence, lack of parametric (and in fact bounded and F-bounded) polymorphism and lack of an assertion (constraint) language. These limitations are over- come by leaving Java as it is, and developing a declarative (query in par- ticular) component of the Java technology. This declarative language is implemented on top of the Java Virtual Machine, extended with orthog- onal and transitive persistence. The model of persistence also features complex name space management. Keywords: Declarative languages, orthogonal persistence, F-bounded polymorphism, Java Virtual Machine. 1 Introduction In spite of the fact that JavaTM [17] is a product of good language design, it exhibits several serious limitations with respect to object-oriented database management. A perfectly valid justification is that it was probably never con- ceived as a database programming language. Yet, some of these database-critical features are important for object-oriented programming in general. The first such limitation is, of course, the lack of support for persistence. Persistence is a key feature of object-oriented database technology [10]. The second limitation is the absence of parametric polymorphism. This lim- itation is particularly critical in database management because most database technologies rely heavily on collections. Static typing of collections in Java is impossible, and so is static typing of queries.